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ABSTRACT 


In the summer of 2008, the Global Combat Support System—Marine Corps (GCSS-MC) 
breached both cost and schedule in development of their ERP system. In addition. Navy 
ERP has had problems, GCSS-Army has been delayed, and the Air Force Expeditionary 
Combat Support System (ECSS) is currently rebaselining their program. Why are all of 
these DoD ERP system development efforts having difficulty and is there a better way to 
implement ERP systems in the DoD? 

This research focuses on DoD ERP implementation efforts ongoing in the Army, 
Navy, Air Force, and Marine Corps. A macro-level review of six DoD ERP 
implementations provides a historical perspective reflecting the difficulty all have had in 
developing their respective ERP systems. A micro-level review of the GCSS-MC 
program identifies systems engineering challenges the program has faced. The 
conclusion is that all Service Components have similar requirements and all struggle with 
development of their respective ERP solution. Much money has been and continues to be 
spent on ERP implementation and each implementation has taken much more time than 
was originally planned. It is important for the DoD to take a hard look at how the current 
ERP solutions have been developed and determine alternate ways to develop similar 
systems in the future. The DoD cannot afford the billions of dollars that have been spent 
on multiple system developments and needs to figure out a way to consolidate efforts 
between the Service Components. These consolidated efforts may provide not only an 
expedited system development effort but also a common system that can be centrally 
managed and used to breakdown the unique stove pipe processes within each Service and 
transform logistics chain management as it is known today. 
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EXECUTIVE SUMMARY 


On August 7, 1990, the deployment of United States (U.S.) forces begun under Operation 
DESERT SHIELD [1], Iraq’s invasion of Kuwait triggered the largest rapid deployment 
of U.S. forces and supplies in history for the planning and movement of troops, 
equipment, and supplies as required by Operation Desert Shield/Storm [2]. Such a 
significant movement of resources to support combat operations requires the use of 
Information Technology (IT) systems to track and manage the logistics chain for all 
supplies and scheduling of maintenance within the theater of operation. 

The use of ERP systems in the DoD is becoming the method of choice to develop 
small increments of capability rapidly. The old method of developing a large amount of 
capability in one increment is too costly, takes too long, and may possibly result in 
implementing out-dated technology by the time the software is released for use. An ERP 
system can be developed one business application at a time and provide a foundation for 
all other business applications to be added later. 

Each Service Component of the DoD is essentially trying to accomplish the same 
goal in modernizing their aging logistics IT systems. Functionally, each Service 
Component is developing redundant capability. Development of logistics ERP systems 
in the DoD have been plagued by cost overruns and schedule delays in the Army, Air 
Force, Navy, and Marine Corps. All Services have experienced similar program 
management and system engineering challenges recognized by the GAO and continue to 
struggle with development of their ERP systems. With the GAO identifying several 
weaknesses in each independent ERP development and with the common technical 
challenges evident across the DoD, would it make sense to develop only one ERP system 
for use across all Service Components instead of developing multiple independent 
Service unique ERP systems? 

This thesis analyzes six of the logistics ERP efforts currently ongoing in the DoD 
and provides an analysis to support the development of a single integrated ERP system to 
be used by all four Services. 
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I. INTRODUCTION 


A. BACKGROUND 

On August 2, 1990, the Iraqi Republican Guard invaded Kuwait and seized 
control of that country. On August 7, the deployment of United States (U.S.) forces that 
became known as Operation DESERT SHIELD began [1], Iraq’s invasion of Kuwait 
triggered the largest rapid deployment of U.S. forces and supplies in history for the 
planning and movement of troops, equipment, and supplies as required by Operation 
Desert Shield/Storm [2]. By 1 February 1991, less than 6 months into deployment, the 
Transportation Command had moved about 440,000 passengers, 3 million tons of unit 
equipment and supplies, and 4.2 million tons of fuel supplies to Southwest Asia in 
preparation for offensive action against Iraq [2]. 

In 2002, the United States and the United Kingdom claimed Iraq possessed 
weapons of mass destruction and posed a threat to their security and that of their allies 
and Operation Iraqi Freedom (OIF) began on March 20, 2003 [3]. Between 1 April 2003 
and June 2003, the Military Traffic Management Command (MTMC)i delivered 42.2 
million meals to Iraq, loaded cargo covering 15 million square feet, transported 1.5 
million tons of equipment and cargo, and moved 98,890 containers [4]. Logistics support 
during OIF was not very timely. The logistics system “pull” processes depended on line- 
of-sight communications that broke down due to lack of connectivity required to assure 
fulfillment of end-user materiel requests. This problem was resolved by emphasizing a 
"push" system that pushed materiel forward without waiting for a request. While the 
ability to identify what containers arriving in theater were carrying was clearly and 
generally much better than a decade earlier in Operation Desert Storm, asset visibility 
after in-theater distribution declined dramatically, probably due in part to the emphasis on 
pushing materiel forward [5]. 


^ MTMC is a Major Army Command (MACOM) that is the overland lift component and primary 
traffic manager for USTRANSCOM [6]. 
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The significant movement of resources to support combat operations required the 
use of Information Technology (IT) systems to track and manage the logistics chain for 
all supplies and scheduling of maintenance within the theater of operation. Desert Shield, 
Desert Storm, and Operation Iraqi Freedom proved to be key events in providing valuable 
lessons learned in how well the United States military IT systems supported logistics 
chain management. During combat operations, the Marine Corps IT ground logistics 
systems did not communicate well, were not integrated, ran very slowly with significant 
lag times, and provided uncertain or unreliable data. The inefficiencies and inaccuracies 
of the IT systems resulted in multiple supplies being ordered with the inability to 
accurately track and distribute the supplies. Something had to be done to modernize the 
Marine Corps ground-based logistics IT systems; thus, the Global Combat Support 
System (GCSS-MC) program was initiated [7]. 

The GCSS-MC IT system is being designed to modernize the Marine Corps 
Logistics IT capability. It is intended to provide the capabilities to execute Marine Air 
Ground Task Force (MAGTF) Combat Service Support (CSS) in expeditionary and joint 
environments. It will improve logistics chain management effectiveness and efficiency 
and will provide actionable combat support information to leadership. Existing Marine 
Corps IT logistics systems are numerous and many are over 30 years old. Support for 
these antiquated systems is disappearing. Several of the Marine Corps ground based 
logistics systems were developed using the Common Business-Oriented Language 
(COBOL) programming language developed in 1959 [8]. One example is the Supported 
Activity Supply System (SASSY). It is a mainframe system developed in the 1970s 
using the COBOL programming language; it is still in use today. SASSY is hard to use, 
contains inaccurate data, and does not efficiently support the war fighter [9]. It is 
becoming increasingly difficult to support as the software requires much patching and the 
COBOL SASSY programmers are becoming harder to find and maintain in the work 
force. The new GCSS-MC system is being built using the Commercial-Off-The-Shelf 
(COTS) Oracle Hi E-Business Suite. This is an Enterprise Resource Planning (ERP) 
software that will not only address the immediate need of an integrated supply and 
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maintenance system, but will be the foundation for the integration and replacement of 
other Marine Corps logistics systems that currently provide warehouse, transportation, 
and many other logistics functionality. 

Operationally, the GCSS-MC software will allow Marines to accurately capture 
data within a shared data environment via a secure connection using the World Wide 
Web (WWW). It will allow the use of Automated Identification Technology (AIT) 
devices, such as hand held scanners and passive and active Radio Frequency 
Identification (RFID) scanners, to input data into a centralized shared data environment. 
Users who are in geographic regions with good Internet connectivity will have direct 
access to the shared data environment. Users who are deployed in remote, austere 
environments will have a local instance of GCSS-MC that will be able to communicate 
back to the centralized shared data environment when communications are up and 
operational [7]. The Operational View (OV), OV-1, is shown in Figure 1 [10]. Figure 2 
shows the flow of information from the Enterprise Server located in the continental 
United States to the forward deployed units in an austere environment [11]. 
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B. PURPOSE 


The use of ERP systems in the DoD is becoming the method of choice to develop 
small increments of capability rapidly. The old method of developing a large amount of 
capability in one increment is too costly, takes too long, and may possibly result in 
implementing out-dated technology by the time the software is released for use. An ERP 
system can be developed one business application at a time and provide a foundation for 
all other business applications to be added later. According to Parr and Shanks [12], an 
ERP may be implemented in one of three ways. The ERP may be implemented in its 
entirety, but it is very complex and can take up to seven years to implement. The ERP 
may be implemented using only a core module without any business process 
reengineering; it is relatively inexpensive but may not provide all of the needed 
functionality. Alternatively, the ERP may be implemented using only a selection of its 
core ERP modules along with significant business process reengineering. This 
methodology is exactly what the Marine Corps decided to do, implement the supply and 
maintenance management capability of the Oracle E-Business ERP in one small 
increment and defer the development of other business areas such as Warehousing, 
Transportation, Planning, Finance, Human Resources, and Engineering to other 
increments. In particular, the Marine Corps has decided to develop capabilities to 
address immediate ground based logistics chain management shortfalls as defined by the 
requirements in the GCSS-MC Capability Development Document [13]. The purpose of 
this thesis is to investigate the ERP development efforts in DoD, understand what makes 
implementation of these development efforts so difficult, and provide a recommendation 
as to an alternate way to develop and implement a single ERP system across all of the 
DoD. 


C. RESEARCH QUESTIONS 

The DoD has selected two main suites of software for their logistics 
modernization ERP efforts. The Army and Navy have selected SAP and the Air Force 
and Marine Corps have selected the Oracle E-Business Suite. Both ERP solutions allow 
the incremental development of capability within the software suite. In the case of 
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GCSS-MC, the Oracle product was best suited to satisfy both the functional and technical 
capabilities as described the GCSS-MC CDD [14], The Marine Corps’ initial focus is 
only on the supply and maintenance management functionality. By first addressing this 
limited functionality, the Program Office increased potential success of meeting schedule 
timelines within budget. However, since the inception of the GCSS-MC program, the 
development effort has still been prone to cost and schedule overruns [15]. 

The following questions will be analyzed: 

• What are the DoD ERP IT system implementation challenges in the Army, 
Air Force, Navy, and Marine Corps? 

• What are the GCSS-MC system engineering technical and functional 
challenges with regards to the design and build of the GCSS-MC system? 

D. BENEFITS OF STUDY 

Development of ERP systems in the DoD have been plagued by cost overruns and 
schedule delays in the Army, Air Force, Navy, and Marine Corps as documented in 
several GAO reports [15, 16, 17, 18]. This thesis will review and analyze the ERP 
development efforts of those services at a high level as well as review and analyze details 
of the GCSS-MC program development effort. Implementation challenges will be 
identified to highlight the difficulties that DoD ERP programs experience and will serve 
as data for a recommendation of how to implement future DoD ERP developments. 

E. SCOPE AND METHODOLOGY 

The scope for this research focuses on DoD ERP implementation efforts ongoing 
in the Army, Navy, Air Force, and Marine Corps. A macro review of six DoD ERP 
implementations provides a historical perspective reflecting the difficulty all have had in 
developing their respective ERP systems. A micro review of the GCSS-MC program 
provides some of the detailed systems engineering challenges the program has faced. 
The methodology, shown in Figure 3, consists of performing two main steps resulting in 
a collection of DoD ERP implementation challenges. 
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Figure 3. Methodology 


1. Review of DoD Service ERP Implementation Efforts 

The Army is developing GCSS-Army and the Logistics Modernization Program 
(LMP), the Air Force is developing Expeditionary Combat Support System (ECSS) and 
Defense Enterprise Accounting and Management System (DEAMS), the Navy is 
developing Navy ERP, and the Marine Corps is developing GCSS-MC. Each service has 
had difficulties in developing their ERP system. This thesis examines each service’s 
difficulties at a macro level and identifies challenges in DoD ERP developments in 
general. 

2. Review of the GCSS-MC ERP Implementation Effort 

This thesis reviews GCSS-MC technical and functional requirements and 
provides a basis for the amount and scope of capability that the Marine Corps is trying to 
develop. The GCSS-MC requirements are very unique than those in the private sector. 
The nature of the Marine Corps to deploy troops on the move in austere environments is 
very different than the private sector’s stationary brick buildings and warehouses. It is 
the uniqueness of those requirements and the complexity behind the implementation of 
those requirements that cause much of the program’s cost overruns and schedule delays. 
The GCSS-MC requirements are analyzed for technical complexity and scope of effort. 
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F. CHAPTER SUMMARY 

This chapter introduces the Marine Corps challenges in management of USMC 
logistics chain management using IT systems that are more than 30 years. The use of 
these IT systems during Desert Shield, Desert Storm, and Operation Iraqi Freedom 
proved that these antiquated systems, while effective for immediate war time situations, 
could actually be more efficient and beneficial to the war fighter if redesigned using a 
distributed, integrated IT system. Modernization of logistics chain management IT 
systems provides a more reliable and accurate logistics management capability that the 
war fighter desperately needs. 

Answers to research questions require analysis of ERP system implementations 
currently within the DoD to understand the system engineering, technical, and functional 
challenges that cause program cost overruns and schedule delays. Analysis of GCSS-MC 
system engineering requirements development identifies challenges that should be 
avoided by the DoD in the development of future ERP systems. 

Chapter II provides a collection of Army, Navy, Air Force, and Marine Corps 
ERP implementation information in terms of GAO findings, functionality, cost, and 
schedule. This comparison serves as the foundation to illustrate the difficulties that these 
DoD services have had in implementing ERP systems. 

Chapter III provides a review of the GCSS-MC ERP implementation effort. The 
program’s systems engineering challenges are identified in the areas of requirements 
development and COTS customization. Functional and technical requirements are 
analyzed with respect to complexity and the amount of customization required to the 
COTS software to provide the required Marine Corps business process functionality. 

Chapter IV analyzes at a high level the implementation challenges of all service 
ERP efforts as well as the GCSS-MC systems engineering challenges. All of which serve 
as potential indicators supporting a recommendation of developing a single ERP system 
to be used by all Service Components. 
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Chapter V provides conclusions and makes a recommendation as to how DoD 
should develop a single ERP system implemented across all Services. It also makes 
recommendations as to areas to conduct further research. 
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II. DOD ERP IMPLEMENTATION CHALLENGES 


A. INTRODUCTION 

The Department of Defense set a goal over 30 years ago to obtain total asset 
visibility (TAV). Per a GAO report [19], the DoD planned to have the total asset 
visibility capability achieved by 2004 and as of July 2007 was still unsuccessful [16]. 
DoD’s new target date to achieve TAV is now 2010 [19]. To meet the TAV goal, the 
Department of Defense has taken on the development of several ERP implementations all 
providing a wide array of capability unique to each service. Each service’s 
implementation is designed to modernize business systems mainly focusing on logistics 
management of assets and financial tracking of those assets. All use ERP software from 
either Oracle or SAP, but each with different levels of scope and functionality designed 
to replace existing legacy logistics IT systems. Many of these legacy systems have been 
in service for over 30 years and support for these systems is becoming scarce. While 
these systems may be relatively inexpensive to maintain as individual systems, the price 
is high in terms of data being stove piped, inaccurate, or not accessible in a timely 
manner. Research and analysis of current legacy systems and the reason for replacing 
them is discussed further in Chapter IV. 

Since 1995, the GAO designated DoD's business systems modernization as high 
risk [18]. The GAO points out that there are many challenges involved with DoD ERP 
implementation. Programs are not aligned to a DoD business enterprise architecture that 
is not fully defined. Program management is weak in the areas of capturing quantitative 
data used to assess overall effectiveness of the overall effort. Programs often provide 
their own internal form of verification and validation and do not rely on those who are 
truly independent of the program to give an honest assessment. Also, best business 
practices need to be applied to provide appropriate management oversight within the 
Department of Defense to ensure programs stay on track [18]. 

The following sections describe existing DoD ERP logistics implementation 
efforts in the Army, Navy, Air Force, and Marine Corps in terms of documentation. 
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capability, schedules, and cost. All of the programs are attempting to transform the way 
the services perform the business of logistics management and all have experienced 
problems, both technieal and programmatic, in the implementation of their respeetive 
ERP systems. This information shows that Army, Navy, Air Foree and Marine Corps 
logistics IT ERP development efforts have experienced several design and development 
problems that need to be understood and addressed in future DoD ERP development 
efforts. 

B. SERVICE ERP EEFORTS 

ERP development effort information was collected from the Army, Navy, Air 
Force, and Marine Corps in four main areas of interest; documentation, funetionality, cost 
and schedule. This information establishes a trend regarding service ERP efforts in terms 
of cost overruns and schedule delays. 

1. Army ERP Efforts 

The Army is modernizing its logistics business proeesses in order to provide total 
asset visibility by implementing two ERP efforts. They are the Global Combat Support 
System-Army (GCSS-Army), and the Logistics Modernization Program (LMP). These 
ERP efforts will modernize the Army’s logistics IT systems that are over 30 years old. 
The GCSS-Army program is an ACAT 1-D program [20] and is a tactical effort that will 
integrate the Army’s supply ehain, provide equipment readiness reports, and get eurrent 
status on maintenance actions and supplies in support of the Warfighter [21]. LMP is a 
wholesale effort that integrates the Army’s supply chain and includes the capability to 
track maintenance activities, as well as provides inventory management, transportation, 
and warehousing funetionality [21]. The following paragraphs highlight the diffieulties 
the Army has had in developing their ERP solutions with respect to GAO key findings, 
functionality, cost, and schedule. 

a. Army ERP GAO Key Findings 

There are many products that are required to fully document the 
requirements of any program. Architecture products are key to not only identifying the 
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current system and process functionality but also the future or desired functionality the 
newly developed system is to provide. Over the years, the GAO has documented several 
findings regarding the inadequacy of architecture development in the DoD. In 2003, the 
GAO identified that the DoD had yet to establish adequate integrated architecture 
governance structure and process controls [22], In 2006, the GAO developed an 
architecture management framework to increase the effectiveness of managing 
architecture programs [23]. In 2007, the GAO identified two critical elements that the 
Army needed to successfully implement the Army logistics ERP; they are an Army level 
Enterprise Architecture (EA) and a Concept of Operations (CONOPS) [16]. 

The EA is a key document that provides a blueprint for organizational 
change. It defines models that represent two states of architecture. One model represents 
how the Army operates today; the other model describes how the Army intends to operate 
in the future. The EA should also include a plan on how the Army should transition from 
today’s operations to the future operations. Without an EA, interfaces and dependencies 
cannot effectively be managed [16]. 

The CONOPS is the key document that describes how the new system 
intends to operate to provide total asset visibility. It details how decisions are to be made 
as well as lay out the new business processes the ERP solution requires to operate in. 
Without a CONOPS, the Army will have a difficult time in describing the enterprise view 
of its new systems as well as not describing the total asset visibility or supply chain 
management processes the Army intends to satisfy using the new ERP systems [16]. 
Documentation of the new business processes should allow the Army to take advantage 
of the COTS product’s ability to transform the Army’s business processes. 

Both the EA and the CONOPS are important documents and provide the 
underlying foundation required to understand the architecture and operation of the ERP 
system. Per the GAO reports, incomplete or inaccurate information in these documents 
could be contributors for cost overruns and delays in schedule. 
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b. Army ERP Functionality 

The Logistics Modernization Program replaces two legacy systems that 
have been in operation for over 30 years, Commodity Command Standard System and the 
Depot System [16]. There are six core Working Capital Fund processes that the Army 
intends to transform, they are: order fulfillment, demand and supply planning, 
procurement, asset management, materiel maintenance, and financial management. 
When fully deployed in 2011, the LMP program will be used by over 17,000 users in 
over 1,000 locations [24]. 

The GCSS-Army program integrates the Army’s supply chain and 
replaces 16 stove-piped legacy logistics systems to include Standard Army Retail Supply 
System, Standard Army Maintenance System Enhanced, Property Book Unit Supply 
Enhanced, and Unit Level Logistics System - Aviation Enhanced and Standard Army 
Ammunition System [20]. It will also eliminate duplicative databases, poor asset 
visibility, and stove piped communications between the Army logistics systems [16]. 

The scope of the GCSS-Army program initially was too large to develop 
as one release. It has been broken down into two main increments with Increment-1 
broken down into three releases and Increment-2 yet to be defined [20]. 

Release 1.0 includes Supply Support Activity (SSA) functionality 
currently implemented at the B DSU SSA, Regimental Support Squadron, 11th Armored 
Cavalry Regiment, Ft Irwin, California [20]. 

Release 1.1 includes Unit Level Supply, Property Book, Maintenance 
(Aviation and Ground), and finance (support to tactical supply and maintenance) 
functionality [20]. 

Release 1.2 includes ammunition, environmental health and safety, 
finance, and cost management functionality [20]. 

Breaking down the scope of GCSS-Army will make the development 
effort manageable and allow smaller increments of capability to be delivered sooner 
rather than waiting for one very large block of capability to be delivered later. 
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c. 


Army ERP Costs 


The cost to develop an ERP system is difficult to budget for and difficult 
to keep within the cost estimate. In 1999, it was reported that approximately 90 percent 
of ERP implementations were late or over budget [25]. In 2003, GCSS-Army started as a 
custom software development and $95 million was invested before the program was 
halted. In 2003, the ERP effort started and as of September 2006, approximately $203 
mi llion had been obligated. It is estimated another $2.1 billion will be invested [16]. As 
of 2006, the LMP ERP effort had obligated about $452 million to develop and implement 
the program and estimated that it will invest at least another $895 million [16]. 

Totaling both LMP and GCSS-Army, a total amount of over $3.8 billion 
will be invested on the development of just these two ERP systems alone. A tremendous 
amount considering COTS software is being used. 

d. Army ERP Schedules 

The LMP effort started in 1998 [16]. It has been operational since 2003, 
and will be fully deployed in 2011. The program will operate in more than 1,000 
locations with more than 17,000 users worldwide [21]. Figure 4 shows that the LMP 
program’s Full Operational Capability (FOC) date had been revised three times 
indicating there were problems with the LMP effort. The revised schedule in February 
2006 modified the FOC to 2011, five years longer than the initial estimate of 2006. This 
is typical of ERP implementations [16]. 
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The GCSS-Army effort started in 1997 as a custom software solution. 
The commercial ERP effort started in 2003. Figure 5 shows that the GCSS-Army 
program’s Full Operational Capability (FOC) date has also been revised three times 
indicating there were problems with the GCSS-Army effort. The revised schedule in 
March 2006 modified the FOC to 2014, five years longer than the initial estimate of 2009 
not counting the custom software development initial FOC date [16]. 


Estimate 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 


Original 
February 2003 


Revised 
August 2005 


Revised 
March 2006 


I I 


Project initiation 

I FOC I Full operational capability 


Figure 5. GCSS-Army Timeline. From [16] 


Both the FMP and GCSS-Army programs had the FOC event rebaselined 
three times. This change in Army FRP schedules is consistent with the schedule delays 
of the FRP efforts of the other DoD Services illustrating that the length of FRP 
development is not easy to determine and even harder to maintain. 

e. Army ERP Effort Summary 

The Army is modernizing its logistics business processes in order to 

provide asset visibility by implementing the FMP and GCSS-Army programs. Both of 

these ERP systems will replace existing legacy systems some of which are over 30-years 

old. The Army was missing fundamental documentation such as the Enterprise 

Architecture, to provide the blueprint for organizational change, and the CONOPS, to 

describe how the new system intends to operate. The functionality of these ERP systems 

includes Supply Support Activity functionality, as well as asset visibility, maintenance, 

finance, and environmental. The scope for the GCSS-Army program was broken down 

into manageable, smaller increments in order to deliver capability quicker to the user. 

The costs for the FMP and GCSS-Army programs are estimated to be approximately 

$1.4B and $2.4B, respectively. Schedule delays have been realized for both the LMP and 
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GCSS-Army programs. The LMP program schedule revised the FOC date by an 
additional five years from the original estimate. The GCSS-Army program also revised 
the FOC date by an additional five years from the original estimate. The Army ERP 
efforts have experienced inadequate documentation, scope redefinition, cost adjustments, 
and schedule delays, as shown in Table 1. 
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Table 1. 


Army ERP Summary 


Area 

Summary 

ERP Programs 

GCSS-Army and LMP 

Key Findings 

Enterprise Architecture and CONOPS not successfully 

implemented 

Functionality 

GCSS-Army 

Supply Support Activity, Unit Level Supply, Property 

Book, Maintenance (Aviation and Ground), and 

finance (support to tactical supply and maintenance) 

functionality, ammunition, environmental health and 

safety, finance, and cost management functionality. 

LMP 

Order fulfillment, demand and supply planning, 

procurement, asset management, materiel maintenance, 

and financial management. 

Life Cycle Cost 

GCSS-Army: $2.4B 


LMP: $L4B 

Schedule 

GCSS-Army: 3 slips within 3 yrs, FOC slip 3 yrs, total 

time to FOC - 11 yrs. 

LMP: 3 slips within 3 yrs, FOC slip 5 yrs, total time to 

FOC - 11 yrs. 
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2. Navy ERP Efforts 

The Navy planned to reform their business operations. Between 1998 and 2003, 
four different Navy commands began to plan, develop, and implement four ERP pilot 
programs [18]. These pilot programs would provide financial management, supply 
management, regional maintenance, and program management capability for the Navy. 
They were developed by four separate commands, were developed independently, and 
duplicated the same functionality. Despite an investment of over $1 billion, the pilot 
programs were uncoordinated, not integrated, and were deemed a failure by the GAO 
[18]. The pilot programs had a lack of disciplined processes to include requirements 
management and customized many areas of the COTS software defeating the purpose of 
using out-of-the-box functionality [18]. 

Because the pilot programs did not meet the Navy’s overall requirements, the 
Navy decided to start over and replace the pilot programs with one ERP system under the 
leadership of a central program office [18]. The replacement Navy ERP solution 
transitions legacy business processes into a single supply solution and integrates the 
functionalities of planning, allowancing, procurement, repairables, and order fulfillment 
[26]. The Navy ERP program developed disciplined processes to identify and manage 
program requirements. The amount of customization was reduced to allow only 
modifications that were required legally or regulatory. Minimizing customizations 
reduced the complexity along with the costs of development [18]. Another area of note 
was the realization that the four pilot projects used the implementation method of their 
separate system integrators. This was a huge risk as each implementation differed 
significantly with respect to the amount and methodology to customize the software. 
Instead, the new integrated ERP solution would implement the methodology of the COTS 
vendor to the overall solution to obtain a more robust requirements management process. 
Requirements can now be linked from the highest level down to the COTS transaction 
level [18]. 

The following paragraphs highlight the difficulties the Navy has encountered in 
developing their ERP solutions with respect to GAO key findings, functionality, cost, and 
schedule. 
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a. 


Navy ERP GAO Key Findings 


The Navy did not designate the four pilot programs as Major Automated 
Information Systems (MAIS) even though they should have been in accordance with 
DoD policy at the time. Because they were not designated MAIS programs, the Navy 
never prepared a mission needs statement for any of the pilots [18]. The mission needs 
statement would have identified the mission requirements and the interoperability needs. 
The current Navy ERP program is designated a MAIS program and is under the oversight 
of the OSD and is required to adhere to the OSD acquisition process rules [27]. This 
designation has increased the probability of success for the program by eliminating the 
mistakes made early during the pilot project efforts. 

b. Navy ERP Functionality 

The Navy ERP program is designed using SAP ERP software. It will be 
developed and implemented in three increments. 

Increment 1.0 includes financials, acquisition, billing, budgeting, and cost 
planning as well as costing, contract awards, and budget exhibits, personnel 
administration, training, and events management [28]. 

Increment 1.1 includes wholesale and retail supply, supply and demand 
planning, order fulfillment, supply forecasting as well as retail supply such as inventory 
management, supply and demand processing and warehouse management [28]. 

Increment 1.2 includes Intermediate-Level maintenance, maintenance 
management, quality management, and calibration management [28]. 

Increment 1.0 provides financials and acquisition capability for about 
36,000 users [26]. Increment 1.1 provides wholesale and retail supply at the Inventory 
Control Point (ICP) and regional supply centers for aggregate total of about 75,000 users 
[26]. Increment 1.2 provides Intermediate (I) level maintenance for both Maritime and 
Aviation for aggregate total of about 80,000 users [26]. When fully implemented, the 
program will support over 86,000 users [28]. 
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Technical challenges for Navy ERP are implementation of 44 system 
interfaces (27 Navy specific, 17 DoD specific), see Figure 6, and data conversion from 
legacy systems into the ERP system. 
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Figure 6. Navy ERP Required System Interfaces. From [18] 


Another challenge for the Navy ERP program is not implementing an 
IV&V function. The Navy ERP program uses in-house subject matter experts and others 
who are also internal to the program. An independent assessor would be able to provide 
unbiased information to the DoD and the Navy on the overall status and effectiveness of 
the management processes [18]. 

Breaking down the scope of Navy ERP will make the development effort 
manageable and allow smaller increments of capability to be delivered sooner rather than 
waiting for one very large block of capability to be delivered later. This also provides 
faster payback and value to the Navy. 
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c. Navy ERP Costs 

The Navy ERP program was rebaselined three times increasing the 
expected life cycle cost estimate each time. Figure 7 shows that costs increased from an 
estimate of $1,873 billion in 2003 to an estimate of $2.44 billion in 2007, an increase of 
over $570 million [28]. This is another example of how difficult it is to estimate an ERP 
development effort and in this case, after four pilot projects had already failed to produce 
a final product. 

Dollars in bi I lions 
3.0 


S2 44 



Fiscal yur 

SoutokGAO nUytit tt OM ditt. 

Figure 7. Navy ERP Life Cycle Cost Estimates. Erom [28] 
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d. 


Navy ERP Schedule 


The start date for the Navy ERP program was in 2003 after the four 
original pilot programs efforts were stopped. At that time, original Navy ERP EOC date 
was 2011. In 2007, the program was rebaselined and the FOC date was revised to 2013, 
as shown in Figure 8. 



Figure 8. Navy ERP Timeline. From [28] 


Once again, here is an example of how difficult it is to develop an accurate 
forecast for the ERP development and implementation schedule. The revision in the 
Navy ERP schedule is consistent with the schedule delays of the ERP efforts of the other 
DoD Services illustrating that the length of ERP development is not easy to determine 
and even harder to maintain. 

e. Navy ERP Effort Summary 

The Navy is modernizing its business operations in order to provide 

financial management, supply management, regional maintenance, and program 

management capability for the Navy. The Navy was initially missing fundamental 

documentation such as the mission needs statement to identify mission requirements and 

interoperability needs. The functionality of these ERP systems includes financials, 
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acquisition, contracting, wholesale and retail supply and demand planning, warehouse 
management, and maintenance management. The scope for the Navy ERP program was 
broken down into manageable, smaller increments in order to deliver capability quicker 
to the user. Technical challenges include implementing 44 system interfaces and data 
conversion from legacy systems. The cost for the Navy ERP program is estimated to be 
approximately $2.44B, an increase of over $570M from the original estimate. Schedule 
delays have been realized for the Navy ERP program. The FOC date was revised by an 
additional two years from the original estimate. The Navy ERP effort has experienced 
inadequate documentation, scope redefinition, cost adjustments, and schedule delays, as 
shown in Table 2. 
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Table 2. 


Navy ERP Summary 


Area 

Summary 

ERP Programs 

Navy ERP 

Key Findings 

Lack of MNS in early pilot programs impacted mission 

requirements and interoperability needs, IV&V 

function not implemented, technical challenges in 

implementation of 44 system interfaces and data 

conversion from legacy systems. 

Functionality 

Increment 1.0 includes financials, acquisition, billing, 

budgeting, and cost planning as well as costing, 

contract awards, and budget exhibits, personnel 

administration, training, and events management 

Increment 1.1: wholesale and retail supply, supply and 

demand planning, order fulfillment, supply forecasting 

as well as retail supply such as inventory management, 

supply and demand processing and warehouse 

management 

Increment 1.2: Intermediate-Level maintenance, 

maintenance management, quality management, and 

calibration management 

Life Cycle Cost 

$2.4B 

Schedule 

Rebaselined once, FOC slipped 2 years, time to FOC is 

9 years 
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3. 


Air Force ERP Efforts 


The Air Force has two commercial off-the-shelf ERP efforts underway using the 
Oracle E-business suite. They are the Expeditionary Combat System Support (ECSS) 
and the Defense Enterprise Accounting and Management System (DEAMS). They are 
components of the Air Force eLog21 systems architecture designed to integrate 
financials, order management, purchasing, inventory management, distribution, and other 
business functions of the Air Force onto one platform [29]. Together they will transform 
the Air Force's logistics and financial management operations and achieve total asset 
visibility. ECSS provides a single integrated logistics system while DEAMS provides 
core financial management capabilities. ECSS is considered a key element in the Air 
Force’s efforts to reengineer and transform its supply chain operations from a reactive 
posture to a more predictive posture that facilitates greater effectiveness and efficiency in 
the Air Force’s logistics operations that support the warfighter [17]. 

The GAO reported in 2008 several key areas that the ECSS and DEAMS 
programs needed to improve upon [17]. The GAO stated that the program’s Risk 
Management process was not adequate enough to capture and manage the program’s 
risks well enough prior to those risks being realized within the program. Program risks 
were managed independently within the working level of the program however the risks 
were not visible at the program management level of the program [17]. 

Several potential risk areas were identified. For both ECSS and DEAMS, 
interfaces were identified and associated risks were managed at the lower program levels, 
however these interface risks were not consistently identified at the program management 
level. Technical challenges that were not identified as risk items include DEAMS having 
70 interfaces to implement and also the level of effort involved in the data conversion 
activities. Other challenges not documented as risks include training and the lack of 
staffing with the required skill sets [17]. 

The following paragraphs highlight the difficulties the Air Force has encountered 
in developing their ERP solutions with respect to GAO key findings, functionality, cost, 
and schedule. 


26 



a. 


Air Force ERP GAO Key Findings 


The Air Force strategy to integrate and govern logistics transformation 
initiatives is stated in the Air Force’s Expeditionary Logistics for the 21st century 
(eLog21) transformation campaign plan [30]. The ECSS and BEAMS programs when 
implemented will satisfy many eLog21 key objectives such as Air Force-Wide logistics 
planning, centralized asset management, total asset visibility, and predictive maintenance 
[30]. The eLog21 serves as a guide that provides a vision to improve Air Force logistics 
to meet both the current and future threat environments and serves as the foundation from 
which program requirements are derived from. 

While the eLog21 strategy provides an overarching guideline for Air 
Force logistics business process transformation, the GAO found that key Air Force 
documentation was not clearly linked together or linked to BoD’s Enterprise Transition 
Plan. Documents such as the Financial Management Strategic Plan, Accountability 
Improvement Plan, and the Logistics Enterprise Architecture Concept of Operations do 
not align to the BoD’s Enterprise Transition Plan. Without this alignment, the Air Force 
will have a difficult time achieving BoD’s business transformation priorities and goals 
that include total asset visibility. 

b. Air Force ERP Functionality 

ECSS and BEAMS is the IT solution to transform its logistics and 
financial management operations leading to total asset visibility across the Air Force. 
The ECSS program provides transportation, supply, maintenance and repair, engineering, 
and acquisition functionality. It will replace 250 legacy logistics and procurement 
systems and will support over 250,000 Air Force users. The BEAMS program provides 
financial management and accounting functions for Air Force general fund operations. It 
has 70 key interfaces and will replace seven legacy systems [17]. 

The ECSS approach to replacing 250 legacy systems in one development 
effort may be problematic. As seen with GCSS-Army and Navy ERP, those programs 
have been broken down into smaller manageable increments of capability. The ECSS 
approach may take a longer time to deliver a larger block of capability. The ECSS 
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program will have many more interfaces to manage, much more data conversion of 
legacy data to deal with, and a tremendous amount of business process realignment to 
implement by trying to replace so many legacy systems at one time. 


c. Air Force ERP Costs 


The ECSS program was initiated in 2004. As of 2007, $250 million had 
been obligated. The ECSS expected total life-cycle cost estimate is over $3 billion as 
shown in Figure 9. This estimate may go higher as more functionality is planned to be 
incorporated into ECSS in the areas of financial management control and accountability 
[17]. 
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Figure 9. ECSS Funding. From [17] 


The BEAMS program was initiated in 2003. As of December 2007, $119 
million had been obligated. The BEAMS expected total life-cycle cost estimate is over 
$1.1 billion, as shown in Figure 10. 
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Figure 10. DEAMS Funding. From [17] 


d. Air Force ERP Schedules 

The ECSS program was initiated in 2004. FOC is estimated to occur in 
fiscal year 2013 [17]. This is 9 years to complete design, build, test, and fielding to all 
units within the Air Force. If the program remains on schedule, and all goes well, nine 
years is probably not too long a time frame to replace 250 legacy systems. However, as 
other DoD ERP implementations have shown with smaller incremental developments, 
there are many challenges to overcome and with the scope of ECSS so large, the 
probability is high that schedule delays will occur. 

The DEAMS program was initiated in 2003. FOC is estimated to occur in 
fiscal year 2014 [17]. This is 11 years to design, build, test, and field to all units within 
the Air Force. With only seven legacy systems to replace, this may be more realistic that 
ECSS, and will have a higher probability of success within the allotted time frame. 

Here is an example of how difficult it is to develop an ERP IT solution 
within a relatively short time span. With such long development times, delays can be 
expected. As seen with the ERP efforts of the other DoD Services even shorter time 
spans are difficult to manage and meet. 

e. Air Force ERP Effort Summary 

The Air Force is transforming their logistics and financial management 
operations in order to achieve total asset visibility by implementing the DEAMS and 

ECSS programs. The Air Force documentation was missing fundamental linkages to the 
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DoD’s Enterprise Transition Plan and will have a difficult time achieving DoD’s business 
transformation priorities and goals. The functionality of these ERP systems includes 
financial management, accounting, transportation, supply, maintenance and repair, 
engineering, and acquisition. The scope for the ECSS program is very large and plans to 
replace 250 legacy logistics while the BEAMS program plans to replace seven legacy 
systems. The lifecycle costs for the BEAMS and ECSS programs are estimated to be 
approximately $1.1B and $3.OB respectively. Schedule delays are likely to be realized 
for both the BEAMS and ECSS programs. The BEAMS program schedule is estimated 
to take 11 years to achieve FOC while the ECSS program is estimated to take nine years 
to achieve FOC. The Air Force ERP efforts have inadequate linkages to BoB 
documentation, very large scope definition, cost increases, and potential schedule delays, 
as shown in Table 3. 
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Table 3. 


Air Force ERP Summary 


Area 

Summary 

ERP Programs 

ECSS and BEAMS 

Key Findings 

Documentation was not clearly linked together or 

linked to BoD’s Enterprise Transition Plan. 

Documents such as the Financial Management 

Strategic Plan, Accountability Improvement Plan, and 

the Logistics Enterprise Architecture Concept of 

Operations do not align to the DoD’s Enterprise 

Transition Plan. 

Functionality 

ECSS 

Provides transportation, supply, maintenance and 

repair, engineering, and acquisition functionality. 

Replaces 250 legacy logistics and procurement 

systems. 

BEAMS 

Provides financial management and accounting 

functions for Air Force general fund operations. It has 

70 key interfaces and replaces 7 legacy systems. 

Life Cycle Cost 

ECSS: $3B 


BEAMS: $1.1B 

Schedule 

ECSS: time to FOC is 9 years 


BEAMS: time to FOC is 11 years 
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4. Marine Corps ERP Efforts 

The GCSS-MC program is the only ERP effort currently being developed in the 
Marine Corps and provides the baseline for the modernization of Marine Corps logistics 
IT systems. It delivers integrated logistics functionality primarily in the areas of supply 
and maintenance. It provides timely and accurate logistics information and is accessible 
by troops in garrison or deployed to austere environments. When fully implemented, 
about 33,000 users around the world will have access [15]. 

a. Marine Corps GAO Key Findings 

In 2008, the GAO identified IT management weaknesses with the GCSS- 
MC program. Two key weaknesses were management of earned value and management 
of risks. The program was not able to adequately measure program progress based on 
actual work performed therefore program completion dates could not be projected 
accurately increasing the likelihood of program delays. The GAO also found that there 
were many risks that had not been adequately managed and that the mitigation steps for 
major risks either had not been implemented or proved ineffective and this allowed risks 
to become actual problems and reclassified into issues. Assessing schedule risk and 
allocating schedule reserve to address these risks within the schedule could not be 
adequately measured, and the GAO believed it likely that program completion dates 
could not be projected [15]. 

b. Marine Corps ERP Functionality 

Per the GCSS-MC ORD and CDD, the GCSS-MC development effort is 
defined as 3 major blocks of capability. These blocks deliver integrated functionality 
across retail and wholesale supply, maintenance, warehousing, transportation, finance, 
engineering, health, acquisition and manpower systems [10, 31]. Block 1 replaces four 
existing logistics IT systems and its functionality is further defined as: 
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• Requesting and tracking the status of products (e.g., supplies and 
personnel) and services (e.g., maintenance and engineering); 

• Allocating resources (e.g., inventory, warehouse capacity, and personnel) 
to support unit demands for specific products; and 

• Scheduling maintenance resources (e.g., manpower, equipment, and 
supplies) for specific assets, such as vehicles [15]. 

GCSS-MC Blocks 2 and 3 are not yet defined and are not planned for 
development until FY12. 

c. Marine Corps ERP Costs 

Cost for the GCSS-MC Block 1 program had been revised three times 
within three years. GCSS-MC originally planned to reach FOC in fiscal year 2007 at an 
estimated cost of about $126 million over a 7-year life cycle [15]. This estimate was later 
revised in 2005 to about $249 million over a 13-year life cycle [15]. At the time of the 
GAO report in 2008, the program expects to reach FOC in fiscal year 2010 at a cost of 
about $442 million over a 12-year life cycle [15]. Figure 11 shows the program’s life 
cycle cost estimate for Block 1 against original and revised milestones. 
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Figure 11. GCSS-MC Program Cost Status. From [15] 

In 2010, in preparation for Milestone C, the GCSS-MC program revised 
its life cycle cost estimate and submitted a proposed Acquisition Program Baseline that 
revised the life cycle cost estimate to $1.022B [32]. This was more than double the 
previous estimate and about 10 times more than the original estimate in 2003. 

d. Marine Corps ERP Schedules 

The GCSS-MC Block 1 program experienced delays early in the program, 
as shown in Figure 12. In 2004, FOC was expected in 2007, but the program was 
rebaselined in 2006 and moved the FOC date to 2010, delaying the program by 3 years 
[15]. 
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Figure 12. GCSS-MC Program Schedule Status. From [15] 


The GCSS-MC program would experience many more delays at almost 
every key event in the acquisition process. Starting with the 2003 ORD schedule and 
ending with the latest schedule that appears in the 2010 Acquisition Program Baseline, 
the FOC for the program was delayed approximately seven years and the total time to 
FOC for the program was revised to about 10 years. This schedule delay pattern is 
consistent with the schedule delays of the ERP efforts of the other services. The 
progression of this schedule delay is outlined in the Research Analysis section of this 
thesis. 


e. Marine Corps ERP Effort Summary 

The GCSS-MC program is the only ERP effort currently being developed 
in the Marine Corps and provides the baseline for the modernization of Marine Corps 
logistics IT systems. It delivers integrated logistics functionality primarily in the areas of 
supply and maintenance. The GAO determined that schedule risk could not be 
adequately measured and that it was likely that program completion dates could not be 
projected accurately. An updated LCCE in 2010 more than doubled the previous 
estimate and was about 10 times more than the original estimate in 2003. There have 
been many delays in the GCSS-MC schedule. The EOC for the program was delayed 
approximately seven years and the total time to FOC for the program was revised to 
about 10 years. Table 4 summarizes the GCSS-MC ERP development effort. 
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Table 4. 


GCSS-MC ERP Summary 


Area 

Summary 

ERP Programs 

GCSS-MC 

Key Findings 

Management of earned value and risks were 

weaknesses and indicative of a program unable to stay 

on schedule 

Functionality 

Retail and wholesale supply, maintenance, 

warehousing, transportation, finance, engineering, 

health, acquisition and manpower systems 

Life Cycle Cost 

$1.022B 

Schedule 

Time to FOC is 10 years, delayed 7 years from original 

estimate 


C. CHAPTER SUMMARY 

Modernization of service legacy logistics IT systems using ERP technology has 
proven to be a challenge to keep on schedule and on budget. The Army, Navy, Air 
Force, and Marine Corps all have similar requirements and trying to implement similar 
functionality. Table 5 shows a side-by-side comparison of the four services. 
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Table 5. 


DoD Services Implementation Summary 



Army 

Navy 

Air Force 

Marine Corps 

GAO Key 
Findings 

Enterprise Arch and 
CONOPS not 
successfully 
implemented 

Lack ofMNS in 
early pilot 
programs impacted 
mission 

requirements and 

interoperability 

needs 

IV&V function not 
implemented 

Technical 
challenges in 
implementation of 
44 system 
interfaces and data 
conversion from 
legacy systems 

Documentation 
was not clearly 
linked together or 
linked to DoD’s 
Enterprise 

Transition Plan. 

Documents such as 
the Financial 
Management 
Strategic Plan, 
Accountability 
Improvement Plan, 
and the Logistics 
Enterprise 
Architecture 

Concept of 
Operations do not 
align to the DoD’s 
Enterprise 

Transition Plan. 

Weak management 
of earned value 
and risk 
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Army 

Navy 

Air Force 

Marine Corps 

Functionality 

GCSS-Army 

Supply Support 

Activity, Unit Level 
Supply, Property Book, 
Maintenance (Aviation 
and Ground), and 
finance (support to 
tactical supply and 
maintenance) 
functionality, 
ammunition, 
environmental health 
and safety, finance, and 
cost management 
functionality. 

LMP 

Order fulfillment, 
demand and supply 
planning, procurement, 
asset management, 
materiel maintenance, 
and financial 
management. 

Increment 1.0 

Financials, 
acquisition, billing, 
budgeting, and 
cost planning as 
well as costing, 
contract awards, 
and budget 
exhibits, personnel 
administration, 
training, and 
events 

management 

Increment 1.1 

Wholesale and 
retail supply, 
supply and 
demand planning, 
order fulfillment, 
supply forecasting 
as well as retail 
supply such as 
inventory 
management, 
supply and 
demand processing 
and warehouse 
management 

Increment 1.2 

Intermediate-Level 

maintenance, 

maintenance 

management, 

quality 

management, and 

calibration 

management 

ECSS 

Provides 

transportation, 

supply, 

maintenance and 
repair, 

engineering, and 
acquisition 
functionality. 
Replaces 250 
legacy logistics 
and procurement 
systems. 

BEAMS 

Provides financial 
management and 
accounting 
functions for Air 
Force general fund 
operations. It has 

70 key interfaces 
and replaces 7 
legacy systems. 

Block 1 

Retail and 
wholesale supply, 
maintenance 

Future Blocks 

Warehousing, 

transportation, 

finance, 

engineering, 

health, acquisition 

and manpower 

systems. 

Service Cost 

$3.8B 

$2.4B 

$4. IB 

$1.022B 

Schedule 

GCSS-Army: 3 slips 
within 3 years, FOC 
slip 3 years, total time 
to FOC is 11 years. 

LMP: 3 slips within 3 
years, FOC slip 5 years, 
total time to FOC is 11 
years. 

Rebaselined once, 
FOC slipped 2 
years, time to FOC 
is 9 years. 

ECSS: time to 

FOC is 9 years 

BEAMS: time to 
FOC is 11 years. 

Time to FOC is 10 
years, delayed 7 
years from original 
estimate. 
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All four Services have exceeded their initial cost estimates as well as experienced 
delays in schedule. While this may not seem unusual in the development of IT systems 
in general, there does appear to be a pattern emerging with ERP systems running over 
cost and schedule. 

The next chapter identifies GCSS-MC system engineering challenges regarding 
the technical and functional requirements and the complexity of implementing those 
requirements. The complexity of the development effort is a large contributor to the cost 
overruns and schedule delays. 
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III. GCSS-MC SYSTEM ENGINEERING IMPLEMENTATION 

CHALLENGES 


A. INTRODUCTION 

The GCSS-MC program chose a COTS ERP product as the best alternative to 
modernize Marine Corps logistics IT systems and satisfy the program requirements 
documented in the GCSS-MC ORD and CDD. The functional and technical 
requirements have remained constant over the life of the program and the requirements 
are traceable between the documents. As the program progressed through the design, 
build and test phases, implementation of those requirements was not as easy as originally 
thought. The program was unable to achieve a MS B decision five years after 
achievement of MS A thus breaching and forcing a rebaseline of the program. This 
chapter discusses the reasons for choosing a COTS product, requirements documentation, 
the functional and technical requirements, and the customization of the ERP software 
needed to meet the Marine Corps required functionality. It is the ambiguity of the 
program requirements and the complexity of implementing those requirements that 
causes the program to run over cost and schedule. 

B. ANALYSIS OF ALTERNATIVES 

In May 2004, the GCSS-MC Program Office performed an Analysis of 
Alternatives to determine the appropriate material solution that would meet the 
requirements defined in the September 2003 GCSS-MC ORD. The five alternative 
solutions of Status Quo, Upgrade Legacy, Custom Implementation, COTS, and 
Outsource were narrowed down to three for evaluation. The results shown in Table 6 
lead the Program Office to choose a COTS solution as it met the most intended scope of 
the system and had the highest return on investment [33]. 
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Table 6 


AOA Results Summary. From [33] 


Area of Analysts 

Alternative 1 

Alternative Z 

Alternative 4 

Status Quo 

Custom 

COTS 

Risk (1-100) 

79 

43 

51 

Functional Requirements (1-500) 

178 

339 

391 

Non-Functional Requirements (1- 
500) 

141 

307 

349 

ROi 

0 

633 

17.28 

Additional Discriminators 

Estimated Cost (Rank) 

1 

3 

2 

Breakeven (w/Benefits) 

3 (Infinite) 

2 (2010) 

1 (2008) 

Discriminator Total 

4 

6 

3 


The AOA analysis results in Figure 13 give a direct comparison of the data and 
clearly show the COTS solution as the desired implementation of choice. 



Figure 13 GCSS-MC AOA Analysis Results. From [33] 

With the COTS ERP material solution chosen, the Marine Corps developed 
requirements and codified them in the May 2005 GCSS-MC CDD. The CDD 
requirements were used as a baseline for defining program cost, schedule, and 
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performance. A COTS implementation was believed to provide several economic 
benefits and avoid pitfalls associated with the conversion of legacy systems to a modern 
architecture. With fewer errors in legacy data conversion, problems of being over 
budget, behind schedule, and technologically inefficient would be avoided [33]. 
However, as shown later in this chapter, the Program Office would face challenges not 
only in meeting a defined schedule but in the planning of a realistic schedule that would 
meet acquisition guidelines contrary to the conclusions in the AOA. 

C. REQUIREMENTS DOCUMENTATION 

The GCSS-MC program has well documented requirements that have remained 
stable throughout its development. While the program has had its difficulties in 
maintaining cost and schedule, the core requirements never changed. Many programs 
suffer from requirements creep but the GCSS-MC program has stayed true to its root 
requirements. 

The 1997 Mission Need Statement (MNS) defined a need to modernize the 
Marine Corps logistics and Combat Service Support (CSS) information technology 
capabilities and to eliminate “stove-piped” development of information technology 
systems [10]. The MNS established the foundation for all future GCSS-MC requirements 
development. 

In 2000, the GCSS-MC Mission Area (MA) Initial Capabilities Document (ICD) 
was approved and defined Combatant Command logistical area functions required for 
execution by the MAGTF. In 2003, the GCSS-MC Operational Requirements Document 
(ORD) established the capabilities for GCSS-MC Logistics Chain Management (LCM) 
and provided the information technology capabilities necessary to execute MAGTF CSS 
functions in expeditionary, joint, and combined environments. 

The ORD defined three major blocks of capability and, in December 2003, a 
System Subsystem Specification (SSS) was developed to translate those high level blocks 
of capability into lower level functional and technical requirements for all three blocks. 
The GCSS-MC/LCM program received Milestone A approval for the first block of 
capability on 23 July 2004 from the Milestone Decision Authority, the Assistant 
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Secretary of Defense, Networks and Information Integration. In May 2005, a Capability 
Development Document (CDD) was created to establish requirements for the first block 
of capability [10]. The CDD requirements are broken down into business process 
subsystem requirements that are translated to component level requirements. The GCSS- 
MC requirements documentation tree is shown in Figure 14. 



Figure 14. GCSS-MC Requirements Documentation Tree 


The GCSS-MC program follows the traditional “V-Model” for development and 
testing of requirements. Requirements are defined, categorized, and traced in detail from 
business requirements to component requirements as shown in Figure 15 [34]. 
Component requirements consist of Reports, Interfaces, Conversions, Extensions (RICE) 
objects that constitute the customization of the ERP software to perform the Marine 
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Corps logistics business operations. It is the development of the RICE objects that define 
the complexity of the ERP design, as shown later in this thesis. 


Initial Capabilities 
OocumEtit 


Deplpyed GCSE-MC/LCM 



Figure 15. GCSS-MC "V-Model". From [34] 


All requirements are captured in a traceability tool from IBM called Rational 
DOORS®. The Eunctional Baseline consists of configuration and business procedure 
documents traceable to a TE.040 test document. The Technical Baseline consists of 
system and sub-system architecture and management documents traceable to a TE.054 
test document. And the RICE baseline, derived from configuration documents, is 
traceable to a TE.050 test document. The GCSS-MC program has a well established 
requirements baseline along with a solid traceability effort, as shown in Eigure 16 [34]. 



Figure 16 . GCSS-MC Traceability. From [34] 
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GCSS-MC is built upon a COTS ERP solution that delivers integrated 
functionality across retail and wholesale supply, maintenance, warehousing, 
transportation, finance, engineering, health, acquisition and manpower systems [10]. 
Accomplishing the development of all of these capabilities in a single effort is very large 
and would take several years to accomplish. The COTS ERP software is designed with 
flexibility such that increments of capability can be developed and implemented in an 
individual fashion. The GCSS-MC program office took advantage of this flexibility and 
divided the development effort into three major blocks of functional capability shown in 
Table 7: 

Table 7. GCSS-MC Block Definition. After [31] 


Block 

Capability 

Block 1 

Retail Supply and 

Maintenance. Deployed 

environment using 

SIPRNET and NIPRNET. 

Block 2 

Wholesale Inventory 

Management, Depot 

Operations, Warehousing, 

Transportation, Enhance 

Order and Inventory Mgmt. 

Block 3 

Advanced Logistics 

Planning, Engineering, 

Medical. 


These three blocks provide the Marine Corps with total Logistics Chain 
Management of all commodities. The functional and technical non-functional 
requirements discussed in Section D provide the baseline capability required by the ERP 
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system. It is the uniqueness of these requirements that causes the ERP out-of-the-box 
software to be customized with the development of RICE objects. Section D discusses 
the complexity of implementing the RICE objects and that proves to be a large challenge 
for the GCSS-MC System Engineering team. 

D. REQUIREMENTS 

The requirements for the GCSS-MC program are represented by two main 
categories. Functional and Technical/Non-Functional. The main purpose of GCSS-MC is 
to provide the basic logistics functions of logistics chain management, specifically, the 
ability to order and track supplies and the ability to schedule and track maintenance. The 
ERP software can perform those basic functions out-of-the-box. There are, however, 
other requirements that are levied upon a DoD ERP implementation that make the 
development effort complex. They are described below in terms of the documented 
GCSS-MC functional and technical requirements. 

1. Functional Requirements 

The GCSS-MC functional requirements are defined by four categories: 

• Top Level Capabilities 

• Joint Financial Management Improvement Program (JFMIP) 

• Standard Financial Information Structure (SFIS) 

• Resource Financial Accounting (REA). 

The Top Level Capabilities provide the baseline functional requirements 
necessary for the system to perform logistics operations and are established in 11 
functional areas defined by the GCSS-MC CDD [10]. These functional areas include the 
basic logistics functions of Inventory Planning, Demand Planning, Mission Planning, 
Maintenance Management and Planning, Asset Management, Inventory Management, 
Service Management, Financial Resource Management, Warehouse Management, 
Reporting System Management, and System Management. The ERP software is very 
capable of providing this basic functionality. The Marine Corps had an existing logistics 
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chain management process in place, however, and the ERP software had to be modified 
to exercise that process. Other complexities are introduced when DoD financial 
requirements (JFMIP, SFIS, and RFA) are placed on the program. 

The JFMIP requirements define the financial management practices in 
government. Specifically it is “... a joint and cooperative undertaking of the U.S. 
Department of the Treasury the General Accounting Office, the Office of Management 
and Budget, and the Offiee of Personnel Management, working in eooperation with eaeh 
other and other ageneies to improve financial management praetices in government” [35]. 
The JFMIP guides financial management improvement across government and explains 
Federal needs by providing agencies information to improve their financial systems. 

The SFIS requirements standardize finaneial reporting aeross DoD by ensuring a 
comprehensive "eommon business language" is used for budgeting, financial accounting, 
cost/performance management, and external reporting across the DoD enterprise [36]. 
The intent of SFIS is to standardize financial reporting across DoD and reduce the cost of 
auditing. To be eompliant means the FRP program must implement the SFIS business 
rules and values in the Business Enterprise Architecture. There are 71 data elements in 
SFIS and they all have specific business rules that address syntax, usage and relationships 
[36]. The SFIS requirements are not part of the ERP out-of-the-box baseline and require 
customization of the ERP software, an unexpected part of the design effort for GCSS- 
MC. 

The RFA requirements ensure that IT systems eomply with regulatory financial 
policies and procedures [37]. Once again, not part of a normal ERP out-of-the-box 
baseline and cause for additional customization of the ERP software. 

The total number of Funetional Requirements derived from these four functional 
categories is shown in Table 8. 
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Table 8. 


GCSS-MC Functional Requirement Count. After [34] 


Requirement Type 

Total 

Top-level Capability 

681 

JEMIP 

315 

SFIS 

36 

REA 

53 

Total 

1,085 


These 1,085 requirements represent the functional capability required to be 
provided by the ERP system for GCSS-MC to perform the core capability of supply and 
maintenance logistics chain management. Once these functional requirements are 
designed, built, tested, and operational, the foundation is set for incorporation of other 
capabilities. It is the uniqueness of these functional requirements that requires 
customization of the ERP software. Any modification to the baseline ERP software 
means additional development time is required and is an opportunity to introduce 
complexity and error in the development phase of the project. 

2. Technical / Non-Functional Requirements 

GCSS-MC is comprised of several key technical components consisting of data 
capture using AIT and the use of a shared data environment accessible via the World 
Wide Web. The Joint Technical Architecture (JTA) framework that defines operational, 
system, and technical architecture views is used to describe and define the GCSS-MC 
system [31]. 

GCSS-MC technical requirements are defined by five categories: 

• Technical 

• Joint Data Element (JDE) Reporting 

• Information Assurance (lA) 
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• Net Ready (NR) Key Performance Parameter (KPP) 

• Visibility KPP 

Technical requirements are those requirements that describe technically how the 
system is to operate. The system must have the ability to be accessed from both a 
garrison and deployed environment and must be able to synchronize data between the 
two environments. Data rates must be in accordance with agreed upon interface controls 
and continuity of operation must be in place to ensure continuous access to the system. 
The requirement to access the system from a deployed environment is very unique to the 
DoD since troops are always on the move, within an austere environment, with normally 
a poor communications infrastructure. This is not normally built into a COTS piece of 
software and requires an extensive research and architecture design effort to properly 
customize the ERP software. 

JDE reporting requirements are specific data elements required to be provided to 
the GCSS-Joint program. Visibility and location of equipment within a theater are 
required to be seen by Joint forces. Availability and accessibility of Marine Corps 
prepositioned assets must also be visible to Joint forces. The JDE requirements add 
additional data fields to the baseline COTS software and require additional interfaces to 
pass that data forward. This extensive modification to and configuration of the COTS 
software introduces complexity into the system design. 

Information assurance requirements are very extensive due to vulnerabilities from 
technology threats and must be applied throughout the system life cycle. lA requirements 
represent the majority of the GCSS-MC technical/non-functional requirements. They 
must be in accordance with DoD lA and acquisition policies and regulations in order to 
protect the mission data [31]. 

There are two GCSS-MC Key Performance Parameters. The first is the Net 
Ready KPP. This states that data-sharing of Net-Centric Operations, Warfare Reference 
Model, and GIG Key Interface Profiles will be satisfied to the requirements of specified 
Joint integrated architecture products and information assurance accreditation [13]. The 
second is the visibility KPP. When connected to GCSS-MC LCM Deployed or 
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Enterprise instances, transactions are visible to authorized users after entry by its 
originator within 60 minutes 95% of the time [13]. These two KPPs bring into play the 
Joint aspect of data sharing and technically the ability to view transactions that are 
dependent on the architecture of the network. Both KPPs require customization of the 
COTS software and increase the development effort of the ERP software. 

The total number of Technical Non-Eunctional Requirements is shown in Table 9. 
These 290 Technical Non-Functional requirements represent the physical and logical 
architecture required to meet the intent of the GCSS-MC ORD. These requirements 
provide an operational architecture that enables the functional requirements to provide 
the deployed warfighter the ability to request and track the status of supplies and services 
in an austere environment. 

Table 9. GCSS-MC Technical Non-Functional Requirement Count. After [34] 


Requirement Type 

Total 

Top-level Capability 

129 

IDE Reporting 

23 

Information Assurance 

133 

NR KPP 

3 

Visibility KPP 

2 

Total 

290 


The Marine Corps requirement to deploy, move, and stand-up capability in an 
austere environment is not typical for a public company in industry and proves to be the 
biggest challenge in this ERP software development. Hence significant customization is 
required. 
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E. CUSTOMIZATION (RICE) 


COTS software by definition is usage of the software, as is, bought straight off the 
shelf. There are two approaches an organization can take when implementing COTS 
software, minimal customization of the software that requires a potential change in 
organizational business processes, and extensive customization of the software to mimic 
the organizations existing business processes. 

The minimal customization approach would save much time and effort in the 
design and development phase and would ensure compatibility of future version upgrades 
of the software. However, this is a very large change management effort and users have 
to be retrained in the new business processes required to operate the new software. 

The extensive customization approach is to have the software mimic the 
organizations existing business processes. This extensive customization requires a large 
software development effort that could take a long time to implement and makes future 
upgrades challenging and technically more difficult [38]. This is the approach of the 
GCSS-MC program. 

The extensive customization approach requires modification of the ERP software 
by developing unique Reports, Interfaces, Conversions, and Extensions commonly 
referred to as RICE objects. RICE objects can be complex and a large number of RICE 
objects can make the ERP implementation very difficult and time consuming. 

Reports are outputs from the ERP software that provide information about the 
data that has been entered [39]. Many existing reports may be used within the new ERP 
software but new reports may need to be created if unique data fields have been utilized 
or reports from legacy systems need to be recreated. Existing legacy reports need to be 
cataloged and analyzed to determine if that report is still needed in the ERP. The ERP 
may offer a better way to output data and legacy reports may not be necessary to create. 
Legacy reports should also be prioritized so that the focus of the initial ERP 
implementation is on the essential reports and not the nice-to-have reports. 

Interfaces may be required to link external systems to the ERP software. An 
interface can be as simple as data exported from the external system and imported into 

52 



the ERP system. An interface can also be very complex if the data movement needs to be 
synchronized between the two systems [39]. The more interfaces, the more technically 
challenging the ERP software development and the more complex the ERP development 
and maintenance. Interfaces can also be troublesome since the ERP system has no 
control over any interface modifications performed on the other end. A rigorous 
configuration management process needs to be in place to ensure all changes to either end 
of the interface do not cause adverse effects on either system. 

Conversions are a deceiving area of implementation and one of the most costly 
areas of implementation [39]. Data clean up is a costly area of implementations in terms 
of labor, the more records the more time consuming [39]. Does the ERP software have 
all the required data fields? Does the legacy data to be transferred conform to the ERP 
standard data format? A standard data import template can be used to map data fields to 
and ensures a consistent, repeatable process to move data from the legacy system. If the 
data to be moved is from a very old system, it needs to be parsed and corrected and that 
can be very time consuming [39]. 

Extensions provide additional functionality that does not exist in the ERP 
software. Often functionality required from the old system does not exist in the ERP 
software and is needed to perform a very specific task. In these cases, a separate program 
must be developed using the tools contained in the ERP system and data hooks are 
created to link the extension to the core ERP [39]. Extensions should be avoided if 
possible [39]. GCSS-MC has 36 extensions in the Block 1 release which seems to be 
high since extensions of any kind should be avoided. 

Reports, Interfaces, Conversions, and Extensions are important and necessary in 
ERP implementations and need to be scoped early in the initial planning phase. 
Insufficient time in the schedule or lack of resources can have a detrimental impact on the 
overall implementation budget [39]. 

The GCSS-MC Program Office selected the Oracle 1 li E-Business Suite as the IT 
solution for modernizing the Marine Corps Logistics IT Systems. The Oracle product 
was selected in part because it is COTS and comes with an integrated suite of capability 
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that the Marine Corps thought could be used without much modification. However, as 
seen in this chapter, a COTS product does not satisfy the functional and technical 
requirements of the Marine Corps out of the box and requires much customization in the 
form of RICE objects. The RICE objects can be very complex given that the Oracle 
COTS product was designed for best commercial practices in the public sector instead of 
for the very specific Marine Corps business processes currently in place, some of which 
have been used over the past 30 years with their existing IT systems. 

One of the first efforts the Program Office performed was a fit-gap analysis. This 
effort consisted of comparing the GCSS-MC requirements against the capabilities of the 
Oracle ERP software. If the Oracle ERP software could not perform the function 
required by the Marine Corps requirement, it was called a gap and the software would be 
modified to meet the requirement with a Report, Interface, Conversion, or Extension 
object. Throughout the development cycle of the GCSS-MC program, requirements were 
continuously reviewed and software design closely monitored to ensure all requirements 
were being met. During the operational analysis (OA) phase of the program, a total of 
1,237 requirements were identified. Approximately 90% of them were deemed to be a 
“fit” leaving the rest to be “gaps” implemented using a RICE object. Table 10 breaks 
down the fit-gap percentages of the requirements. 

Table 10. OA Phase Fit-gap Requirements 



# Requirements 

#Fit 

#Gap 

%Fit 

Request Management 

158 

137 

21 

87% 

Supply 

515 

482 

33 

94% 

Maintenance 

216 

183 

33 

85% 

Finance 

189 

165 

24 

87% 

System Admin 

159 

146 

13 

92% 

Total 

1237 

1113 

124 

90% 


As the program progressed, the number of requirements was refined and the 
Fit/Gap percentage evolved as shown in Figure 17 [40]. It is interesting to note that there 
is an 83% fit of the GCSS-MC requirements to the COTS out-of-the-box software. That 
may appear to be a very good fit but it’s not only the number of RICE objects that 
determine the size of the design effort but the complexity of the customization required. 
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Fit/Gap Analysis 
(FUE/IOT&E 
Implementation Phase) 
7 Oct 2009 


Rqmts 

959 

Fit 

794 

Gap 

165 

Flt% 

83% 

RICE 

101 


Figure 17. Fit/Gap Analysis 

With only an 83% fit of the requirements to the ERP software capability, 
development and implementation of the RICE objects was critical to the success of the 
GCSS-MC effort. Almost 20% of the GCSS-MC requirements required RICE objects 
and this meant a more complex design and implementation. It was this complex design 
that drove the project cost overruns and schedule delays. The Program Office recognized 
the complexity and decided to design and implement the Block 1 effort in two releases as 
shown in Figure 18 [41]. 



Figure 18. GCSS-MC Two Release Strategy. From [41] 
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The two release strategy allowed the Program Office to field the baseline functional 
capability and get the system to users quicker while continuing to develop the much more 
difficult technical aspects of deployment with a multiple instance architecture 
incorporating the data synchronization and SIPRNET capability. Table 11 shows the 
allocation of RICE objects between the two releases. The more technically challenging 
Data Synchronization and Cross Domain Solution were moved into Release 1.2 allowing 
the baseline functionality of Reports, Interfaces, Conversions, and Extensions to be 
developed in a timely manner. 

Table 11. RICE Allocation 


RICE Type 

Release 1.1 

Release 1.2 

Cross Domain Solution 

0 

8 

Data Synchronization 

1 

34 

Reports 

18 

1 

Interfaces 

29 

13 

Conversions 

17 

1 

Extensions 

35 

1 

Total 

100 

58 


With the technically challenging RICE objects of cross domain solution and data 
synchronization moved into Release 1.2, the GCSS-MC program can field the basic 
capability of supply and maintenance management sooner to the war fighter and speed up 
the process of eliminating the legacy supply and maintenance systems. 

F. GCSS-MC SCHEDULE HISTORY 

The GCSS-MC program projected a delay in schedule with almost every 
acquisition document produced or at each milestone event. Each new schedule produced 
reinforces the fact that the initial or previous schedule was unrealistic. This can be due to 
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many factors such as expectations from the Marine Corps to hold fast to desired dates and 
the program office’s day to day challenges of implementing an ERP system. The 
following sections describe the chronological events and corresponding acquisition 
documents that represent the important milestone dates at that time. A trend emerges as 
the milestone dates change constantly ultimately causing a breach in program schedule 
and forcing the program to rebaseline. 

1. Pre-Milestone A 

According to the GCSS-MC ORD dated September 2003, the IOC for GCSS-MC 
will be at the end of fiscal year 2004 and the FOC for GCSS-MC will be during FY-2006 
[31]. The plan is to field GCSS-MC to 35,000 users at three Marine Corps bases, several 
supporting establishments, and in-theater locations around the world. In September 2003, 
when the ORD was written, the CDD requirements had not been written. The scope was 
defined at a very high level within the ORD and the material solution had not been 
selected. Milestones had not been defined, only an IOC and FOC had been determined as 
shown in Figure 19. In order to meet an IOC in the fourth quarter of FY2004, much work 
had to be done from development of requirements and architecture, to build and test, to 
train and field. That is much to accomplish in only a one year period from ORD 
requirements to a users hands-on-keyboard. 



ORD SCHEDULE (Sep 2003) 


FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 


Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Milestones 





























Reviews 





























Operational 

Capability 




IOC 








FOC 



















Date of Schedule 


Actual Event Date 


No Change from Previous Schedule 



Change from Previous Schedule 


Figure 19. GCSS-MC ORD Schedule 


The 2004 Acquisition Strategy/Acquisition Plan (AS/AP) defined a program 
strategy to first select a COTS vendor and then acquire a systems integrator [42]. The 
program office chose the Oracle Hi F-Business Suite as its COTS material solution and 
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selected a systems integrator. A fit-gap analysis was performed to see how well the 
Oracle software satisfied the documented program requirements. 

The program office defined milestone events along with a Design Readiness 
Review (DRR) and Full Rate Production (FRP) review. Figure 20 shows that IOC was 
delayed two years and FOC was delayed one quarter. It is remarkable that the program 
thought it could achieve FOC only three to six months after IOC considering fielding is 
to be to approximately 35,000 users [31]. Note that there is only one year between the 
MS A and MS B events. That means requirements must be established, contracts put in 
place, fit/gap analysis performed, architecture developed, system designed built and 
tested, and users trained and fielded to all within one year. That is very aggressive. 



AS/AP SCHEDULE (May 2004) 


FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 


Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

Milestones 



A 



B 





C 


















Reviews 







DRR 





FRP 

















Operational 

Capability 












IOC 

FOC 


















Date of Schedule 


Actual Event Date 


No Change from Previous Schedule 



Change from Previous Schedule 


Figure 20. GCSS-MC 2004 AS/AP Schedule 


2. Milestone A Achieved 

The GCSS-MC program achieved MS A in July 2004. With the Oracle Hi 
E-Business suite selected as the material solution, a systems integrator selected, and 
program requirements defined in a CDD, a fit/gap analysis was performed. The program 
schedule shown in Figure 21 depicts a one quarter delay in the MS B decision but all 
other dates holding true to the previous AS/AP schedule. Overall, not much of a delay 
considering the program had advanced one full year. Still ambitious to think FOC 
follows IOC by only three to six months. 
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CDD SCHEDULE (May 2005) 


FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 


Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

01 

Q2 

Q3 

Q4 

01 

02 

03 

04 

01 

02 

03 

04 

Milestones 




A 



B 




C 


















Reviews 







DRR 





FRP 

















Operational 

Capability 












IOC 

FOC 


















Date of Schedule 


Actual Event Date 


No Change from Previous Schedule 



Change from Previous Schedule 


Figure 21. GCSS-MC CDD Schedule 


In January 2006, the GCSS-MC program terminated the contract it had with its 
systems integrator and in February 2006, the program selected a different company to be 
the new system integrator to determine the high-level architectural, technological, and 
configuration requirements to support the functional and information needs of the system 
[42]. This shift in systems integrators caused a new approach to system design using the 
new system integrators software development methodology. A fit/gap Analysis, RICE 
object list, and a Conceptual Architecture were developed and technical challenges arose 
[42]. A combination of switching to a new systems integrator and the discovery of the 
technical challenges caused delays in the program and a new schedule was developed and 
reflected in the November 2006 AS/AP shown in Figure 22. MS B, MS C, and IOC were 
delayed by about two years and FOC was delayed by about two and a half years. Note 
that more time was inserted between IOC and FOC, about nine months, but even that 
added time would prove to be a bad estimate as shown later in this thesis. 



AS/AP SCHEDULE (Nov 2006) 


FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 


01 
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03 

04 

01 

02 

03 

04 

01 
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03 

04 
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03 
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02 
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04 
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04 

01 
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Reviews 
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Date of Schedule 


Actual Event Date 


No Change from Previous Schedule 



Change from Previous Schedule 


Figure 22. GCSS-MC November 2006 AS/AP 
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The March 2007 System Engineering Plan did not refer to milestones or 
lOC/FOC dates so the indication is that they remained the same as the dates in the 2006 
AS/AP. Figure 23 shows no delays since the AS/AP schedule from five months back. 



SEP SCHEDULE (Mar 2007) 

FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 
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Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

Q1 

Q2 

Q3 

Q4 

01 

02 

03 

04 

01 

02 

03 

04 
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Reviews 















DRR 





FRP 









Operational 

Capability 




















IOC 



FOC 








Date of Schedule 


Actual Event Date 


No Change from Previous Schedule Change from Previous Schedule 


Figure 23. GCSS-MC 2007 System Engineering Plan 


3. Milestone B Achieved 

MS B was achieved in April 2007 only one month after the expected date stated 
in the AS/AP. The schedule was revised at MS B, MS C and FOC were delayed by about 
six months and IOC by three months. However the program was still on track to achieve 
IOC within five years of MS A. Objective and Threshold values were introduced for the 
first time in the APB, objective dates are shown in Figure 24. 



APB SCHEDULE (Jun 2007) Objective Dates Shown 


FY2004 

FY2005 

FY2006 

FY2007 

FY2008 

FY2009 

FY2010 


01 

02 

03 

04 

01 

02 

03 

04 

01 

02 

03 

04 

01 
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03 

04 

01 

02 

03 

04 
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03 

04 

01 

02 

03 

04 
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FRP 







Operational 

Capability 





















IOC 




FOC 






Date of Schedule 


Actual Event Date 


No Change from Previous Schedule 



Change from Previous Schedule 


Figure 24. GCSS-MC MS B APB Schedule 


The GCSS-MC program is an ACAT 1 program required to submit Major 

Acquisition Information System (MAIS) Quarterly Reports (MQR). In the September 

2008 MQR, the GCSS-MC program reported it was likely to breach in the areas of cost 

and schedule and would fail to achieve IOC within five years of MS A [43]. A Critical 

Change Team (CCT) was formed to evaluate the program on cost, schedule, and 

technical performance. The CCT determined that the program would breach cost and 
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schedule and recommended that the program rebaseline and revise its acquisition strategy 
to include a two phase implementation approach. The Block 1 program would be split 
into two releases. Release 1.1 would provide the enterprise functional baseline and allow 
users to access the system from anywhere in the world as long as they had a high speed 
internet connection. Release 1.2 would provide access to users who were deployed in an 
austere, poor communication environment. Figure 25 shows the proposed rebaseline 
schedule compared to the MS B baseline schedule. 


GCSS-MC/LCM Block 1 Program Schedule Comparisons 

I CY2005 I CY2006 | CY2007 | CY2008 | CY2009 | CY2010 | CY2011 | CY2012 | CY2013 
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Figure 25. GCSS-MC CCT Schedule Comparisons. From [43] 


The CCT recommendation drastically changed the acquisition strategy of the 
program. The new schedule allowed the program to defer the harder, technically 
challenging aspects of the program (data synchronization and cross domain solution) to a 
later release while providing the baseline functional capability of the system sooner to the 
user. With the accepted new CCT schedule shown in Figure 26, the GCSS-MC program 
was on a path to achieve a new MS C date in first quarter FY2010. 
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Figure 26. GCSS-MC CCT Rebaseline Schedule 
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Preparations for MS C were now ongoing in accordance with the new CCT 
schedule. Even with the revised schedule, the program office realized that MS C would 
not be achievable as planned in first quarter FY2010. The November 2009 System 
Engineering Plan being prepared for MS C depicted a modified schedule, shown in 
Figure 27, that delayed both MS C and IOC by six months still within the six month 
threshold values. 



SEP SCHEDULE (Nov 2009) 
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Figure 27. GCSS-MC MS C System Engineering Plan Schedule 

The February 2010 AS/AP prepared for the MS C event kept most of the dates 
stable. The FRP was renamed to Full Deployment Decision (FDD) and was delayed by 
six months. The FOC was renamed to Full Deployment (FD). The dates in Figure 28 
show that the program is now stabilizing and preparing to go into a Functional User 
Evaluation in second quarter of 2010. 
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Figure 28. GCSS-MC MS C AS/AP Schedule 


The April 2010 APB prepared for the MS C event is shown in Figure 29. IOC 
was deleted; however Release 1 of GCSS-MC was initially fielded to the Marines in III 
MEF during the Field User Evaluation (FUE) event and could be considered an IOC for 
all intents and purposes. All other dates have stabilized and the GCSS-MC program 
office is on track to fully field the Block 1 capability to the Marine Corps in second 
quarter FY2013. 
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APB SCHEDULE (Apr 2010) Objective Dates Shown 
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Figure 29. GCSS-MC MS C APB Schedule 


The IOC and FOC dates in the 2003 ORD were very ambitious and it was 
unrealistic to believe that IOC could be achieved in 2004 and FOC could be achieved in 
2006. It was not until second quarter 2010 that users could access the system and it will 
not be until second quarter 2013 that GCSS-MC will be fielded to the entire Marine 
Corps, about six and a half years after the original dates specified in the ORD. 

G. CHAPTER SUMMARY 

The GCSS-MC Analysis of Alternatives analyzed five alternative solutions of 
Status Quo, Upgrade Legacy, Custom Implementation, COTS, and Outsource. The 
Program Office chose a COTS solution as it met the most intended scope of the system 
and had the highest return on investment [33]. 

Requirements have been stable in the GCSS-MC program and a traceability effort 
has ensured that all requirements are traceable and are being met. The GCSS-MC 
functional and technical requirements are very unique and extensive customization of the 
COTS software is required. Only 83% of the programs requirements can be met by the 
COTS ERP software out-of-the-box. Customization of the ERP software using RICE 
objects is critical to meeting all of its functional and technical requirements. The 
development of the RICE objects has introduced a complexity that has caused the 
program to overrun the budget and delay the schedule. The Program Office has 
recognized that the complexity in the program lies in the technical challenges and has 
separated the development effort into two releases. This strategy allows the basic 
functionality to be delivered to the user sooner than the more technically challenging 
multi-instance capability. 
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When the GCSS-MC program chose a COTS product as their material solution to 
modernize the Marine Corps logistics IT systems [33], the belief was that a product used 
widely in industry could easily be adapted to suit the business practices of the United 
States Marines. Throughout the development of GCSS-MC, every time a new schedule 
would appear in either a systems engineering or acquisition document, the dates for key 
acquisition events would move to the right. Granted, there was an unexpected change in 
the system integrator, and that by its very nature can cause a schedule delay, but the 
technical challenges were not anticipated and feasible schedules could not be developed. 

In retrospect, the original IOC and FOC dates in the 2003 ORD were very 
ambitious. It was not until second quarter 2010 that users could access the system and it 
will not be until second quarter 2013 that GCSS-MC will be fielded to the entire Marine 
Corps, about six and a half years after the original dates specified in the ORD. 
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IV. RESEARCH ANALYSIS 


A. INTRODUCTION 

The development and implementation of DoD Service Component ERP logistics 
IT systems has a history of cost overruns and schedule delays. All are trying to 
modernize their logistics IT systems. How do the ERP implementations of the four 
Services compare? Are they trying to implement the same functionality? Are they all 
facing the same challenges? If so, why should the DoD spend as much money as they 
have in six systems when one system could be developed to be used by all four Services? 

In the case of the GCSS-MC program, there were technical challenges to 
overcome. A detailed look at the GCSS-MC program reveals a level of complexity that 
was unexpected and not factored into the development effort. What lessons are learned 
and how can those lessons apply to future ERP developments? 

B. SERVICE COMPONENT EUNCTIONAL ANALYSIS 

Each Service Component has designed their ERP system to provide logistics 
chain management to modernize their logistics IT systems. The DoD has adopted a 
methodology called the Supply Chain Operations Reference (SCOR) model to help 
describe the business activities associated with all phases of satisfying a customer's 
demand [44]. SCOR was first investigated by the Navy as part of a supply-chain 
management project in 1997-'98 [44]. All four Services have applied the SCOR model 
in some way. The Marine Corps has used it as a guide to help consolidate its information 
systems, the Navy has used it to help benchmark its process performance, the Army has 
studied its best commercial practices, and the Air Force has incorporated some of its 
metrics in its organizational scorecard effort [44]. The DoD’s use of the SCOR model 
may explain why there is so much commonality between the Service ERP efforts. 

The SCOR model uses the high level functions of Plan, Source, Make, Deliver, 
and Return [44]. The SCOR definition of these functions were very generic but could be 
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mapped loosely to the ERP functionality of the Service Components. Figure 30 shows 
the functional hierarchy of the ERP functions as they pertain to the SCOR high-level 
functions. 



Figure 30. Functional Hierarchy 


An analysis of the functional needs of each Service shows that in 10 out of 13 
categories, functionality is common in two or more of the Services and in about half of 
the categories functionality is common in about half of them. This implies that the 
Service Components have been developing redundant capability and have been spending 
billions of dollars to solve the same problems. Service Component functions are broken 
out by category in Table 12 and a comparison of those functions show that a 
commonality exists across many of the development efforts. 
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Table 12 


Service Component Functional Comparison 


Top 

Level 

Function 

# 

Category 

Army 

Navy 

Air Force 

Marine Corps 

Plan 

1 

Manage 

Supply 

Supply Support 
Activity 

Unit Level 

Supply 

Order 

fulfillment 

Demand and 
supply planning 

Annnunition 

Wholesale and 
retail supply 

Supply 

forecasting and 

demand 

processing 

Order 

fulfillment 

Demand 

planning 

Supply 

Retail and 
wholesale 
supply 

2 

Manage 

Acquisition 


Acquisition 

Events 

management 

Acquisition 

Acquisition 

3 

Manage 

Warehouse 
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management 
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Warehouse 

management 

Inventory 

management 


Warehousing 

4 

Manage 

Health and 
Safety Records 

Environmental 
health and safety 



Health 

5 

Manage 

Personnel 


Personnel 

administration 


Manpower 

systems 

6 

Manage 

Engineering 

Support 



Engineering 

Engineering 

Source 

7 

Schedule 

Maintenance 

Materiel 

maintenance 

Aviation and 

Ground 

Maintenance 

Intermediate- 

Level 

maintenance 

Maintenance 

management 

Maintenance 
and repair 

Maintenance 

8 

Manage 

Finances 
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management 

Finance support 
to tactical 
supply and 
maintenance 

Cost 

management 

Financials 

Billing 

Budgeting 

Costing and 

Cost planning 

Budget exhibits 
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Top 

Level 

Function 

# 

Category 

Army 

Navy 

Air Force 

Marine Corps 


9 

Administer 

Contracts 

Procurement 

Contract 

awards 

Procurement 


Make 

10 

Manage 

Quality 


Quality 

management 



11 

Manage 

Calibration 


Calibration 

management 



Deliver 

12 

Manage 

Transportation 



Transportation 

Transportation 

13 

Manage 

Training 


Training 




With so much commonality between the ERP development efforts, a case can be 
argued that the DoD should pursue only one ERP solution that can be used by all Service 
Components. 

C. SERVICE COMPONENT ERP DEVELOPMENT ANALYSIS 

All DoD ERP development efforts addressed in this thesis are trying to modernize 
their logistics chain management IT infrastructure. All are going through the same basic 
System Engineering process steps of conceptual design, preliminary design, detail design 
and development, production/construction, and operational use and system support [45]. 
All have experienced the same challenges as they try to implement similar capability and 
functionality. 

The modernization of logistics IT systems is a necessity as some of the legacy 
systems are approaching being in service close to 40 years. Many of the programming 
languages have been in use for many years, some for decades, and require very senior 
software engineers to maintain them. Most if not all of these systems were built in a 
stove-piped fashion with no common interfaces making it difficult to track the 
authoritative data source for items and necessary to keep the same information in 
multiple systems. All four Service Components have the need to modernize their 
logistics IT infrastructure yet all are independently tackling the job. 
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There are many ways to develop a new logistics IT infrastructure. New programs 
can be written with current modem day programming languages. There are many 
programs that specialize in one aspect of logistics management. All four Service 
Components did not go either of these routes; instead they all chose an ERP COTS 
solution. This decision allows one suite of software to be used for not only specialized 
logistics functions, but allows management of the entire logistics chain. This provides 
cross functionality between the ERP modules and reduces the need for development of 
additional stove-pipe systems. All four Service Components chose a separate ERP 
solution and decided to implement their system independent from one another. 

Implementation of an ERP in its entirety is a very large undertaking. All Service 
Components scoped the size of the ERP development effort into smaller increments. 
This incremental methodology allows a much more manageable effort with opportunities 
to add on to the baseline system at a later date. Not all of the Service Components started 
with the same functionality in their initial baseline, however. If a narrow enough scope is 
defined, it may be possible to focus development on that capability for use by all four 
Service Components. 

The use of ERP COTS software allows the user to begin development with any 
particular functionality inherent in the complete software suite. All are providing, or 
planning to provide, much of the same functionality such as ordering a part, scheduling 
maintenance, tracking assets, tracking finances, planning and tracking distribution, and 
planning cost. While each Service Component may have started their development 
efforts with different initial capabilities in mind, ultimately the intent is to focus on 
complete logistics chain management, a common capability that each Service Component 
needs. 

The intent of each Service Component is to replace their existing logistics IT 

systems with a modernized state of the art logistics chain management IT infrastructure. 

This entails the movement of information from the legacy IT system to the ERP system. 

Legacy data must be cleaned, reformatted, and moved in a consistent manner from each 

of the legacy systems. This allows the ERP system to view legacy data and maintain a 

history of information regarding logistics transactions from the past. Each Service 
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Component has to move legacy data to the new ERP system. This is a very consistent, 
rigorous, and repeatable operation that can be reused over and over again, not just by one 
of the Service Components, but shared by all to ensure a consistent transfer of data. 

Once the ERP system has been developed it must be fielded to the user. All 
Service Components have many users in several geographic locations. All require users 
to be “moved” from using the legacy system to using the new ERP system. This requires 
extensive training of not only the new ERP system but the understanding of how to 
perform legacy processes within the new ERP system. Once again, this is a very 
consistent, rigorous, and repeatable operation that can be reused and shared by all Service 
Components to ensure that all users get trained in a uniform and consistent manner. 

Summarized in Table 13, there are many commonalities between all of the ERP 
development efforts. It can be argued that this commonality presents a case for the DoD 
to pursue only one ERP solution that can be used by all Service Components. 


Table 13. 

Service Component Commonality 

Common Item 

Description 

Modernization of Logistics IT 

- Replace very old logistics IT systems. 

- Unsupportable legacy systems. 

- Stove-piped legacy systems, data not easily 

transferred. 

Using ERP Concepts 

- Cross functionality between logistics management 

functions. 

Incremental Development 

- Multiple releases. 


- Reduce scope to a manageable level. 
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Common Item 

Description 

Functionality 

- Ordering a part. 

- Scheduling maintenance. 

- Tracking assets. 

- Tracking finances. 

- Planning and tracking distribution. 

- Planning cost. 

Legacy Data Conversion 

- Data movement from legacy to ERP system. 

Legacy System Cutover 

- “Move” users from using the legacy system. 

- User ERP training. 

- User process training. 


D. GCSS-MC IMPLEMENTATION ANALYSIS 

The GCSS-MC ERP development effort has had many challenges since its 
inception in 2003. Review of other DoD services ERP development efforts within the 
Air Force, Army, and Navy show that the schedule delays encountered by the GCSS-MC 
program are “normal.” The GAO has written several reports, many referenced in this 
thesis, regarding the challenges encountered in ERP developments within DoD and there 
are many factors involved ranging from unrealistic schedule planning to unexpected 
design complexity of the ERP system. 

As the GCSS-MC program progressed through development, more and more 
information was learned regarding the time required to design, build, and test the system. 
At each major milestone or critical stage of the GCSS-MC program the schedule was 
modified. Figure 31 shows that IOC was delayed 6.5 years and FOC was delayed 6 years 
from the original GCSS-MC ORD estimate. The delays were enough to cause the 
program to breach schedule and fail to reach MS C five years after achievement of MS A. 
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Figure 31. Marine Corps Schedule Trend 


The GCSS-MC program’s acquisition approach was modified several times due to 
systems integrator issues and program complexity. While the core requirements 
remained stable throughout development, the overhead of implementing financial 
requirements increased the complexity of the effort. The implementation of the core 
requirements required a logical split between functional availability to the enterprise 
users and accessibility to the deployed users. It was the complexity of the RICE objects, 
in particular the RICE objects for data synchronization and SIPRNET, that created a 
delay in schedule, drove an increase in cost, redefined the scope size of the effort and 
influenced the program to adopt a two release strategy for the first block of GCSS-MC 
capability. This two release strategy reinforced the philosophy that designing and 
implementing smaller increments of capability over short periods of time allows 
capability, even if it is reduced from the original plan, to be fielded earlier to the user. 
The GCSS-MC Program challenges are summarized in Table 14. 
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Table 14. GCSS-MC Program Challenges 


Challenge 

Description 

RICE Objects 

- Data conversion and interface complexity. 

Schedule 

- Delays due to unexpected complexity. 

Cost 

- Increase cost due to schedule delays. 

Scope Size 

- Scope split into smaller increments due to schedule 

delays. 

Requirements Definition 

- Additional requirements due to unexpected 

financial requirements. 


E. CHAPTER SUMMARY 

There are many commonalities between the four Service Components ERP 
development efforts. All have chosen an ERP solution to modernize their logistics IT 
systems. All have very similar functionality being developed and implemented in 
multiple, reduced scope releases. All have to convert data from legacy systems and all 
have to train users on how to use the new ERP, as well as the corresponding business 
processes. 

All four Services have experienced many similar challenges that have caused cost 
overruns and schedule delays for all the programs. These overruns and delays are due to 
program complexity in the areas of data conversion and interface development along with 
unexpected requirements that are required within the financial community. The question 
becomes why should the DoD spend as much money as they have in six systems when 
maybe one system could be developed to be used by all four Services? 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

This research focused on DoD ERP implementation efforts ongoing in the Army, 
Navy, Air Force, and Marine Corps. A macro-level review of six DoD ERP 
implementations provided a historical perspective reflecting the difficulty all have had in 
developing their respective ERP systems. A micro-level review of the GCSS-MC 
program identified systems engineering challenges the program has faced. The 
conclusion is that all Service Components have similar requirements and all struggle with 
development of their respective ERP solution. Much money has been and continues to be 
spent on ERP implementation. Each implementation has taken much more time than was 
originally planned. It is important for the DoD to take a hard look at how the current 
ERP solutions have been developed and determine alternative ways to develop similar 
systems in the future. The DoD cannot afford the billions of dollars that have been spent 
on multiple system developments and needs to figure out a way to consolidate efforts 
between the Service Components. These consolidated efforts may provide not only an 
expedited system development effort but also a common system that can be centrally 
managed and used to breakdown the unique stove pipe processes within each Service and 
transform logistics chain management as it is know today. 

Table 15 provides a summary of the recommended ERP implementation 
methodology activities. 
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Table 15. ERP Implementation Recommendation Summary 


Effort 

Actual (Today) 

Recommended 

DoD ERP 

- Separately managed efforts 

- Single centrally managed 

Implementation 

by four Service Components. 

effort. 

Build and Design 

- Individual System Integrator 

- Multiple System Integrator 


contracts. 

contracts. 


- Multiple System Integrators 

- Single System Integrator 


and implementation 

and implementation 


methodologies. 

methodologies. 

RICE Objects 

- Severe customization. 

- Conform to core software 

functionality and change 

business processes of each 

Service. 

Test 

- Decentralized. 

- No change. 

Fielding 

- Decentralized. 

- Centralized cutover 


- Unique cutover processes. 

processes. 


- Unique training processes. 

- Centralized training 

processes. 

PDSS 

- Decentralized. 

- Centralized. 


- Multiple PDSS contracts. 

- Single Contract. 


- Multiple configurations. 

- Single configuration. 


- Multiple release 

- Single release management 


management efforts. 

process. 
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Each Service Component of the DoD is essentially trying to accomplish the same 
thing by modernizing aging logistics IT systems and streamlining multiple systems into 
one complete, coherent, and accurate logisties ehain management system. All have 
eommon implementation strategies but each has unique requirements that represent the 
core business processes of each Service. All have experienced similar program 
management and systems engineering challenges recognized by the GAO and continue to 
struggle with development of their ERP systems. 

The GAO determined there were many weak areas in each of the DoD ERP 
efforts such as: 

• Unsuccessful implementation of Enterprise Architectures and CONOPS, 

• Lack of MNS in early pilot programs, 

• Lack of IV&V implementation, 

• Technieal ehallenges in implementation of system interfaces and data 
eonversion from legacy systems, 

• Requirements documentation not elearly linked together or aligned to 
DoD’s Enterprise Transition Plan, 

• Weak management of earned value and risk. 

Many of the GAO identified weak areas impact each Service’s ability to 
accurately determine the time it will take to design, build, test, and field their respective 
ERP system. An example is GCSS-MC’s history of continuing to revise the development 
schedule at almost every major acquisition milestone and new release of system 
engineering documentation. The government inherently has a lack of knowledge of how 
ERP systems work and does not understand well enough the funetional gaps between the 
COTS software and the Service Components requirements. In addition, there are 
potential scope size challenges that may require development efforts be broken down into 
smaller manageable pieces in order to deerease the complexity of the effort. The GCSS- 
MC program recognized the eomplexity and technical challenges in customizing the 
COTS product and moved the RICE objects for the cross domain solution and data 
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synchronization capability into Release 1.2 allowing the GCSS-MC program to field the 
basic capability of supply and maintenance management sooner to the war fighter and 
speed up the process of eliminating the legacy supply and maintenance systems. 

The application of a COTS product in a DoD environment is much different from 
that in the private sector. COTS products do not provide unique DoD or Service 
Component functional and technical capabilities to support things such as mobility of 
troops and poor communication networks in austere environments. This is much 
different than stationary brick and mortar buildings with solid and stable communication 
links. Therefore, the perception of buying a COTS product to minimize development 
effort is exactly that, a perception. In addition to not supporting the functional and 
technical requirements, the COTS product does not provide the unique Service 
Component business processes nor does it provide the unique DoD SFIS and JFMIP 
financial requirements. The implementation of the unique DoD requirements translates 
to a large development effort in terms of customization and configuration. 

All Service Component ERP development efforts discussed in this thesis are 
similar in nature and are trying to accomplish the same end goals. The functional 
analysis shows that the Service Component’s are developing redundant capability. The 
GAO has identified several weaknesses in each independent ERP development. The 
technical challenges that GCSS-MC has faced are common across the DoD. Would it 
make sense to develop only one system for use by all of the Service Components that 
would address all of the GAO identified weaknesses and minimize the functional and 
technical challenges experienced by the DoD? 

B. RECOMMENDATIONS 

There is a common functional capability desired by all four Services as they all 
try to achieve the same goal of modernizing their logistics IT systems. All four Services 
have already determined and chosen the COTS ERP product as their IT solution. The 
GCSS-MC Program AOA has shown that a COTS ERP product is the desired 
implementation method since it uses industry best practices and best meets the defined 
capability of the Marine Corps [33]. A COTS ERP system, by its very nature, provides a 
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single integrated package of capability that is common to all four Services. With each 
individual DoD ERP development effort referenced in this thesis demonstrating severe 
cost overruns and schedule delays, the recommendation is to develop a single ERP 
system that can be used by all four Service Components. 

Developing a single integrated COTS ERP solution for all four Services is 
consistent with and satisfies much of the intent of the DoD Information Enterprise 
Strategic Plan, 2010-2012 [46]. The intent of the Strategic Plan is to share information 
across DoD and with mission partners, in summary this includes: the information itself; 
the Department’s management over the information life cycle; the processes associated 
with managing information to accomplish the DoD mission and functions; activities 
related to designing, building, populating, acquiring, managing, operating, protecting and 
defending the information enterprise; and sharing of related information resources such 
as personnel, funds, and equipment [46]. Being a shared system used across DoD, a 
single integrated COTS ERP solution provides everything the Strategic Plan intends and 
provides the basis for the following recommended implementation methodology. 

Development of a single integrated ERP system provides many advantages such 
as : 

• Reduction of the number of logistics IT systems to maintain - saves 
billions of development and sustainment dollars, 

• Asset visibility across Services - locate and provide gear to war fighter 
faster and more efficiently, 

• Shared data in same place - logistics data available to all Services to make 
better informed Command and Control decisions, 

• Common transportation and distribution - reduce number of deliveries and 
get gear to war fighter quicker, 

• Procurement streamlining - shared transactional procurement data to 
eliminate unnecessary duplication of gear. 
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• Consistent processes - train all DoD supply personnel on same processes 
and provide ability for Services to move personnel between Services. 

To develop such a system, a Lead Service or external entity could act as the 
Program Office and manage the entire life cycle support of the system. The ERP COTS 
solution should be developed using centralized design, build, and sustainment efforts for 
all of the Services and decentralized test and field efforts within each of the Services. 
Centralized design and build efforts ensure common requirements are defined and 
implemented through a common infrastructure and establishes a solid baseline for 
commonality across the Service Components. Decentralized test and fielding efforts are 
required to account for the unique networks of each Service as well as the number of 
geographic locations and number of systems to be subsumed. The ERP development 
activities of Design, Build, Test, Eield, and Sustain are depicted in Eigure 32 and 
discussed in the following sections. 
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Figure 32. ERP Development Recommendation 


1. Centralized Design 

The design of the ERP solution needs to address requirements from all four 
Service Components. Technical requirements should be fairly standard. These include 
the ability to access the system from any environment with excellent or poor 
communication networks and the ability to handle a very large number of users. The 
functional requirements should also be fairly standard, that is, the same business 
processes to be used by all the Services. Examples are the ability to order a part, 
schedule maintenance, or track assets. However, this presents a tremendous change 
management issue for all of the Services since the functional requirements, when 
standardized, will most likely not resemble the current way business is being done in any 
of the four Services. The advantage is that a common language for logistics management 
is established, standard processes are exercised, and all Services conform to one system. 
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Now consolidated training can be provided to all Services and users from each Service 
can actually perform the function on behalf of a sister Service in time of need. This 
means very detailed planning is required up front to ensure the common set of funetional 
requirements address all of the Services functional needs. 

2. Centralized Build 

The build of the ERP solution will be very data intensive. RICE objects are a big 
eause for eoneern because of the complexity they introduee. Any RICE objeets that are 
common across the Services should be incorporated into the core baseline ERP software. 
To minimize the development of RICE objects, the developer should go to great lengths 
to use existing funetionality already inherent within the ERP COTS software, however, 
there will be some RICE interface objects required sinee not all Serviees conneet to the 
same internal and external systems. There may also be some unique reporting 
requirements for each Service Component and customized reports may be required to be 
developed. 

There are several other commonalities that can be obtained during the build effort. 
The use of a common data conversion template allows a rigorous, repeatable, process to 
convert data from a legacy system. The development of a common data dictionary 
ensures that all data elements are defined once and used many times by all Service 
Components in a standardized way. 

3. Decentralized Test 

Test efforts are decentralized and allocated to the respective Service Component 
for implementation. This is due to the uniqueness of the network for eaeh Service and 
aeeommodates the unique interfaees that eaeh Serviee must be able to test. This may 
make it difficult to maintain a single baseline for all four Services since four individual 
test efforts will be ongoing and may discover problems required to be fixed in the core 
baseline. This requires an extreme amount of eoordination between the Services to 
manage the eonfiguration of the baseline software. 
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4. Decentralized Fielding 

Fielding efforts are decentralized and allocated to the respective Service 
Component for implementation. Each Service has a unique number of locations and a 
unique number of systems to convert and is responsible for implementation of fielding at 
a local level. 

Each location demands not just training users on how to use the new system but 
training users on how the new system relates to the old system processes. This is part of 
the change management effort and it is important to convey the relationship between the 
old and new processes. Local Field Service Representatives will also be available to 
assist local users on how to use the system when the new ERP system is initiated for the 
first time. 

Each location requires conversion of unique legacy system data into the new ERP 
system. All data from the legacy system must be cleaned, reformatted, and converted for 
accuracy and ability to be retrieved from the new system. 

Even with Service unique location and legacy system conversion requirements, 
standardized processes can be still be implemented across the Services. Cutover and 
training processes can be standardized to be repeatable and with the appropriate data 
templates, data conversion can also be standardized. 

5. Centralized Sustainment, Post-Deployment System Support (PDSS) 

After the ERP solution has been designed, built, tested, and fielded, the system 
will need to be sustained and maintained. Configuration and Release Management 
become very important as the system is used and patches, enhancements, and 
modifications are made to the system. A Help Desk is established for user support in 
times of technical assistance, training, or problem solving in general. Centralization of 
PDSS means a single contract is needed to maintain support of ERP efforts for all four 
Services. 

The above five activities provide a potential method to develop a single ERP 
system for logistics chain management in the DoD. At a glance, the recommendation to 
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develop a single ERP system across Services appears to have merit, however, even a 
single system development effort will have several challenges that need to be analyzed, 
socialized, and bought into by the Service Components. 

C. AREAS TO CONDUCT FURTHER RESEARCH 

This research can be further conducted in a few areas. These areas include: 

• ERP System Deployment Options. Analysis can be conducted on how 
best to deploy an ERP system. This should include not only consideration 
of the DoD acquisition process but also the methodology used by private 
industry. 

• Single DoD ERP Logistics System Feasibility. This thesis recommended 
a single system to be centrally managed and developed and used across all 
four Services, but how feasible is that? Are the individual Services 
willing to give up their long time used stove piped business processes for a 
common way to do logistics business across the DoD? 

• ERP System Scoping Options. Analysis can be conducted to determine 
the best approach to “right size” the initial scope for a universally 
developed DoD ERP logistics chain management implementation. What 
is the right functionality to be developed for all Service Components to 
initially start with and how is that functionality determined? 
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